From nobody Thu Apr 2 12:05:41 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1B53A0CA9 for ; Thu, 2 Apr 2020 12:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h3fnBMPQn1f for ; Thu, 2 Apr 2020 12:05:31 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03D13A0CB2 for ; Thu, 2 Apr 2020 12:05:29 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 3D4B4893A3; Thu, 2 Apr 2020 21:05:25 +0200 (CEST) From: Fernando Gont To: IPv6 Operations References: Message-ID: Date: Thu, 2 Apr 2020 15:49:49 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [v6ops] Fwd: WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Apr 2020 19:05:39 -0000 Hello, folks, Long time no hear! I hope all of you and your beloved ones are fine in these crazy times. v6ops is WGLC'ing one of the documents (https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-01) we have authored to improve the reaction of SLAAC to renumbering events. This document contains recommendations for Customer Edge Routers. For background, you may want to consult: https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01 If you have any comments/feedback, please do let us know. If possible, on the v6ops list (https://www.ietf.org/mailman/listinfo/v6ops) Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Date: Mon, 30 Mar 2020 15:47:14 +0000 From: Ron Bonica To: v6ops@ietf.org Folks, This message initiates a WG Last Call on draft-ietf-v6ops-cpe-slaac-renum. Please submit comments by April 13, 2020.                                   Fred and Ron Juniper Business Use Only -- 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 Apr 3 08:54:55 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2281F3A1974 for ; Fri, 3 Apr 2020 08:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GhENNGvfJuF for ; Fri, 3 Apr 2020 08:54:52 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C26D3A1973 for ; Fri, 3 Apr 2020 08:54:52 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id h15so9097458wrx.9 for ; Fri, 03 Apr 2020 08:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=7dNGIt+/KzNkpklBgfq+ZPd/UyIh41XY5MfJz4VNjDI=; b=JJZ9sLJhgaS+faFjsYxKhZQmUbbMv0KlENoAdIVxh/8t0TBAOm5yMNhyG7RP+ULCpQ dxwJuucrgS9dBVQ56yQcF70Rz5bJP1cvTPXyAAUbsFFudpkoZ+AOTBbjGWWS8rzhPXUL HCOiabVNWIKzfbQ6YdUyR/YfoguseQbUPy7NRsT9W6QJnkG0s7/a8k3N4pSi30o/YDj8 l/WO0CEuU10pvH8nBBq878+c+yjEuTx/JW9GKBPjLuEnBqXyY6PveMf/blu31hip2o9s 4tVxt2dlr6hxiZfPTSMAYwrVbOS/GzOV6fHGYRWuJ0UsgpqwnUWCqJo0D/YWN2exqRxq U7eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=7dNGIt+/KzNkpklBgfq+ZPd/UyIh41XY5MfJz4VNjDI=; b=TnwKZu0mrEeyLWN1JG/pC45q3D8XEXbDoHU1ml6Du+7CTaaoqlg+RoXK+liwaSdGub lajO+92CNfO19qt2w6iAy38GoXvAtyBYreYzCeGGAUUkoOt1ybbUf8mLkGKg80wzzU6B Vv7ET+9+UqpxYgcibQ7PpKCGvMM7QojwgoIKovWPcrGm7fA7dMxswCT8alcW2FHv36xH srBRZR9a1wCysmZsdYKYnPK9uCjmesPJn1zK0iggoo7xp1pQJxzNkhkLa//GwG92ijTK ku++7TZJVttKB861omFvLYfQZ1DjdlTN4K1XSqlp9iP0DDr9V6HZTRIRtTRFVYJe8jPv Dlsg== X-Gm-Message-State: AGi0PubQVtW5F+NHEQsaOTqkNruJzOPpvRvCecdMRA9+qZSr7u0EmRuf DsfOagDVfhjCITaFLFEfFV0fT3jb X-Google-Smtp-Source: APiQypJvG5HJnMCBayRRgu76pLEWkTMZEBfpkGAuBXUxsLE838ppV3vVnRrv9f+PGB+3uiBNEen5Mg== X-Received: by 2002:a5d:544f:: with SMTP id w15mr5475512wrv.62.1585929290536; Fri, 03 Apr 2020 08:54:50 -0700 (PDT) Received: from ?IPv6:2600:8802:5900:13c4::102c? ([2600:8802:5900:13c4::102c]) by smtp.gmail.com with ESMTPSA id t26sm2949830wmj.12.2020.04.03.08.54.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2020 08:54:49 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_6FE2E11A-C738-45B1-9520-FDD2DE9E229B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 3 Apr 2020 08:54:47 -0700 References: To: IPv6 Operations In-Reply-To: Message-Id: <0D10FD07-A26A-4456-B358-CE1D9A454777@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2020 15:54:54 -0000 --Apple-Mail=_6FE2E11A-C738-45B1-9520-FDD2DE9E229B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes. In short, we had several people say that the topic was something = they wanted to kick around, so we made it a working group draft. Ron and = I are now looking for working group comments on it, in the absence of = which we can't tell the IESG there is support. Are there any opinions on = this document? > On Apr 2, 2020, at 11:49 AM, Fernando Gont = wrote: >=20 > Hello, folks, >=20 > Long time no hear! I hope all of you and your beloved ones are fine in = these crazy times. >=20 > v6ops is WGLC'ing one of the documents = (https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-01) we = have authored to improve the reaction of SLAAC to renumbering events. = This document contains recommendations for Customer Edge Routers. >=20 > For background, you may want to consult: = https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01 >=20 > If you have any comments/feedback, please do let us know. If possible, = on the v6ops list (https://www.ietf.org/mailman/listinfo/v6ops) >=20 > Thanks! >=20 > Cheers, > Fernando >=20 >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum > Date: Mon, 30 Mar 2020 15:47:14 +0000 > From: Ron Bonica > To: v6ops@ietf.org >=20 >=20 >=20 > Folks, >=20 > This message initiates a WG Last Call on = draft-ietf-v6ops-cpe-slaac-renum. >=20 > Please submit comments by April 13, 2020. >=20 > Fred and Ron >=20 >=20 > Juniper Business Use Only >=20 >=20 >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_6FE2E11A-C738-45B1-9520-FDD2DE9E229B 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+AFAl6HXEcACgkQEhdRnd2G P+A9pA/8Cf5J4Ki5S25N/PwiyRip42zD0PeL7ktEPdNljNb/4SloKdV8tVZ4hTlx 6L9AChDpG2KtYTLFhpZZSmhCT4yc0yC0PLlMXWBrjUGaHrnMB5Q6z/Y0BqXftB/I hBvUkEpojXlVxCLQRmHVg+cwogwY1clLcsvfufKEKtK7/9/ValMQpdHeC5+P8Ibb u1TQIAElrGQ5YjHyo5b38GgBnUkQ+x7Pcz3TA1kA4QL9amaG2X0HQHU7pNdeLnZL TKKCwNl3Si5pntreqYCxI5YuhUrXIZHUXrAjlTC1ATVvLXtAyOU7NC+gBpJoqfBV fg16MsaEH3Zh0AjRmldX+H70LxIE6RI4xOrW8xmrKoy9TSLiSvay0W5DKsI/D/0l UhhgBDWbp0x/ZyRalNUZsa8bAhim/vCnVsRwvtKj1oZ3TgHD1ePv7bI2K58L+Lj7 dJriQSctv4Jj3R0KLM2IICxqVQwd/wsvTW8qEgjYkR8ygq26OqP2DWjN9xsfTdSm wnxaWXe9RuEucKovT8JOcq2/xdAg1RWQKD9if4q4jrUSKmj/4CbUt5nL/AqHVMBR acsKK3DOPP7+8I0yItkYosHXx9gH2BxIc6AHrQ5j41JV1lKB4Zfyt8Vi2fOmi4qh vERRnt0o0nmEGhnHDvXH1hgC3o0OGvhGnHLo1ne+MvydVCKbvGU= =hD1O -----END PGP SIGNATURE----- --Apple-Mail=_6FE2E11A-C738-45B1-9520-FDD2DE9E229B-- From nobody Fri Apr 3 09:43:18 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9F63A0405 for ; Fri, 3 Apr 2020 09:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fM2ukxYd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=w1Xi43M5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Wv9lI7awsTP for ; Fri, 3 Apr 2020 09:43:15 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14773A03FE for ; Fri, 3 Apr 2020 09:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3706; q=dns/txt; s=iport; t=1585932195; x=1587141795; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mbCvu4wM1bQDHelOztEuKg5jiep5j95oxT3k7TA+fko=; b=fM2ukxYdEjsMqMw4//9T/Pa3eb1mRSqnxDtvjcPT7F2yJGKnYpZfEkSg VUgKlZwsypc8lDv8tML+aHAz8tHLRBtA1wX+DxbvAenO4ztGpbn8SqIKi T5vrfl4Tlf3y5zmF4CqUXpNqKMjV6PwaATJvxmBlypZ38azFZhdU2xRgs c=; IronPort-PHdr: =?us-ascii?q?9a23=3A3YHLER+UMZU9EP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/YR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfJq3UeaNpJXh?= =?us-ascii?q?4Bh98Rmlk+B8qXIUb6N/XtKSc9GZcKWQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAQBKZ4de/5tdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gVRQBWxYIAQLKgqHVgOKY06CEZMxhG2CUgN?= =?us-ascii?q?UCgEBAQwBARgLCgIEAQGERAKCRiQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFaQc?= =?us-ascii?q?BAQEBAgEBARAoBgEBLAwEBwQCAQgRAwEBAQEeECcLHQgBAQQBEggaEweCa4J?= =?us-ascii?q?LAw4gAQ6kAwKBOYhigieCfwEBBYEvAQMCg3oYggwDBoE4hSINhwIaggCBEUO?= =?us-ascii?q?CTT6CZwEBAgGBZINCgiyMOaRdCoI9h2+PU4JMiDiQfIs7g3eJI5J6AgQCBAU?= =?us-ascii?q?CDgEBBYFpIoFXcBU7gmlQGA2OHQwXg1CFFIVBdAKBJ40ZAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.72,340,1580774400"; d="scan'208";a="470666841" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Apr 2020 16:43:14 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 033GhElG022813 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Apr 2020 16:43:14 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 11:43:14 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 11:43:14 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 3 Apr 2020 11:43:14 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ScvUCGoghRHULgF+oR2Ccn4Fl2c9mlXxzRFl735/zTj4bb0ZdQDMgFa/n0BFK51C0BBwgya6IRvRI0+qZaznRcHCxmgPqEJrbLmnzfsutYlqNTokHysLN+XYhGg3wXH26bSKKqM9S1t611ih24J1UJay1skxPYmeO2uIdDiiSe7VFCFhNvsJ6vL0ChCgGe5cZl+XBDNXd01ehvsoeCRvVHiz61udi6iiq0Fjnr2xc6IvORrjqsMgnmvvD7Q7PZi9ojnLUJm/qlu28Cqe+qFPRSYQ2eRvD4z1S5OI3KCyqmQU0HalkdA/Cw2dpLv/TYOvObi5gLPuXJ/v66aipfVXwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M6oi3K2LXYPv+fUAsI78f4cnVAW2J/jGSL0Rrpnahk0=; b=Gf9GdIAN0GCKoOdhZVily3+2qiiuuiVuYSBby40w0Bv6J1uhz4wZOZI1hEVHymd1E8PSgj802jDrOOysWongQ9K++mpderzGqHDEqTvALJZjrM7oYbG6P+IBbPVa3cjiC4w1Y/x/nqDve5WJqvRPIuFPo2QLfQo5TMrqCh+0A4vtC9NGDvrkdzuDldWpun9QQaXaeE71V0Hk1I3TwVShX4IIfzDO2Sq9DOYLslOc52VYZQdZkoBGzVWMIdA47pj8iYpdidGolP6DqCdHsHD8GXRFnvfR28aup8S0V/FKVoM/tVywP0sOsLHYWJQ3rcMUWaDjSnABuuBv20GHesf2ig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M6oi3K2LXYPv+fUAsI78f4cnVAW2J/jGSL0Rrpnahk0=; b=w1Xi43M5Pn55jG+v3TB9J/8cvVH/LhV6P9VUP2yv+KTgKybbzNXzKoOY5o+io7OP7278yFKqWL1AuufXCTmP+Fk4V6cDjyZSkOZaidMzwaq64d53L9O5fk/9ckAZFNnSGKAo5diLMWWn+jjeAaW2EGlaOyc7nRpRJCGY3/dHT0k= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2530.namprd11.prod.outlook.com (2603:10b6:406:ac::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Fri, 3 Apr 2020 16:43:13 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Fri, 3 Apr 2020 16:43:12 +0000 From: "Bernie Volz (volz)" To: Fred Baker , IPv6 Operations Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdYGqnrRGOoD4f0yRz2uh9FnYboxrQDJdGHbAADG6AA= Date: Fri, 3 Apr 2020 16:43:12 +0000 Message-ID: References: <0D10FD07-A26A-4456-B358-CE1D9A454777@gmail.com> In-Reply-To: <0D10FD07-A26A-4456-B358-CE1D9A454777@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b8bda6a-9914-49e3-ee3f-08d7d7ee199d x-ms-traffictypediagnostic: BN7PR11MB2530: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(376002)(136003)(39860400002)(366004)(396003)(81156014)(52536014)(5660300002)(66446008)(81166006)(64756008)(66946007)(66476007)(76116006)(8676002)(8936002)(66556008)(9686003)(55016002)(2906002)(86362001)(33656002)(966005)(71200400001)(478600001)(26005)(186003)(6506007)(53546011)(7696005)(316002)(110136005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KWA99w/TZsIVlUKaSALa8tDl9winSnb1B0vpsyRxXqdURO1yq/FMKwC7VSBlt9/u9F/ww5D5KoYgElod0xmJUpYrb6a49DScrzKUlz0sNM1JTSKjsgUDiegSvBwC7EpUzDVoI7nIWvdTJVS89xaF49zDXscQuoHqGHxUem2lCEQz5ZgT9GUtUODROsWOVySlF94PUYLuCLw8UPYSz6mDxGKTB0xDtwoxN5d2L0zED3mxUZoM6+RfOVOoQgTrS5IhXp5hj4uvg8XyjzB7FBrizF10ulCjiFAKLTBUIeZNtYnDDdAG+Yzb0CcpVAjJtXBgGFef8H/tJrmeSaNhOAbjdAJbuv5/vseQWg2neyf10BqgQ2ZM2QQqsAaavCUlLUKnBs/u8ynlRm5yjawXYqEWiRLCW7fu11pYexsfw4McML6ZpA8weTltl6zL+Jh/NNqFSlqGlc/kK2yH9wCSTF/bcrr6zwE9FuaUxMs4XhgV0jSHIDl8gjQ95azrGi/MWmv59LkqwIN8qP/1SePJgRuxRA== x-ms-exchange-antispam-messagedata: KSp2d7qWrpINQ9vnIwFJkDwqMSlRuQRLTv18p/Awhg7OJpen1GJ8wondGk/0fLUbc1A2i53zK66fRrznLsKwoegg6AahWlq6Ss2gcggHBT2qBLGXEWufiTBBCq0vukGpR1sObZ2AusCPAcxFK6QHJg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4b8bda6a-9914-49e3-ee3f-08d7d7ee199d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 16:43:12.6744 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UAsSDsYl496zEtUBmXKzAyo7AWdehkTaM81VS2FPYEWWBFLaLnTxV4zmGqHgx+6D X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2530 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2020 16:43:18 -0000 Hi: I think this is useful work and did send comments to Fernando offline as mi= nor nit (as part of comment on another document). Sorry, as I missed the fa= ct that this was in WGLC. Basically, in section 2.2, I think it should be made clear how long any sta= le configuration must be "retained" to send in RAs to assure that informati= on is properly deprecated - which is that it must be retained until the lon= gest valid lifetime it was ever advertised with has elapsed. The above suggestion is in line with a related discussion for the draft-gon= t-6man-slaac-renum document, where perhaps the CPE should cap the lifetimes= it advertises in RAs. Though it may also be something to consider adding t= o Section 2.1 of cpe-slaac-renum (i.e., a CPE may cap the lifetimes adverti= sed in RAs). The current text only says that they must not be greater than = the (remaining) DHCP lifetimes. And I also just noticed there is a need to clean up the reference that stil= l points to the individual submission: [I-D.gont-v6ops-slaac-renum] Gont, F., Zorz, J., and R. Patterson, "Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events", draft-gont-v6ops-slaac-renum-02 (work in progress), February 2020. It is somewhat confusing with the 3 documents (draft-ietf-v6ops-cpe-slaac-r= enum, draft-ietf-v6ops-slaac-renum, draft-gont-6man-slaac-renum) as they ha= ve similar names. - Bernie -----Original Message----- From: v6ops On Behalf Of Fred Baker Sent: Friday, April 3, 2020 11:55 AM To: IPv6 Operations Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Yes. In short, we had several people say that the topic was something they = wanted to kick around, so we made it a working group draft. Ron and I are n= ow looking for working group comments on it, in the absence of which we can= 't tell the IESG there is support. Are there any opinions on this document? > On Apr 2, 2020, at 11:49 AM, Fernando Gont wrote: >=20 > Hello, folks, >=20 > Long time no hear! I hope all of you and your beloved ones are fine in th= ese crazy times. >=20 > v6ops is WGLC'ing one of the documents (https://tools.ietf.org/html/draft= -ietf-v6ops-cpe-slaac-renum-01) we have authored to improve the reaction of= SLAAC to renumbering events. This document contains recommendations for Cu= stomer Edge Routers. >=20 > For background, you may want to consult:=20 > https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01 >=20 > If you have any comments/feedback, please do let us know. If possible,=20 > on the v6ops list (https://www.ietf.org/mailman/listinfo/v6ops) >=20 > Thanks! >=20 > Cheers, > Fernando >=20 >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum > Date: Mon, 30 Mar 2020 15:47:14 +0000 > From: Ron Bonica > To: v6ops@ietf.org >=20 >=20 >=20 > Folks, >=20 > This message initiates a WG Last Call on draft-ietf-v6ops-cpe-slaac-renum= . >=20 > Please submit comments by April 13, 2020. >=20 > Fred and Ron >=20 >=20 > Juniper Business Use Only >=20 >=20 >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint:=20 > 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Apr 3 09:45:27 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB7A3A0736 for ; Fri, 3 Apr 2020 09:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Ma1Md2Fq2ASD for ; Fri, 3 Apr 2020 09:45:24 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 43DE23A0659 for ; Fri, 3 Apr 2020 09:45:24 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 033GjLD73036502 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 3 Apr 2020 09:45:21 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 033GjLD73036502 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1585932321; bh=Ndbfrs4fmf+JTcRDNS0T2w5xcwwwyJ1NY8zHGEk9fhw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=16EixFAqL6CvHntv60ykMmeiA+9yF04LUTQYhsSMX9WXdBPCfaVfjZaogePGuOnY4 2F8Ic0p8ei7hL0fEV/X5ySQIBYu0dU2cMw7h8tubRmtBoHKki7pwd5C3EHprJGwMz9 OKALk3aBY4jxzBuoXLDlAB/9wxBKAD3h43ZpXhZA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: Date: Fri, 3 Apr 2020 09:45:21 -0700 Cc: Fred Baker , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <17DD0AC7-95AF-4AE0-848B-E2C0CE0155F9@delong.com> References: <0D10FD07-A26A-4456-B358-CE1D9A454777@gmail.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 03 Apr 2020 09:45:21 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2020 16:45:26 -0000 Support. This is a topic that is worthy of being covered in an informational RFC = and the consideration in this draft is well done. Owen > On Apr 3, 2020, at 09:43 , Bernie Volz (volz) = wrote: >=20 > Hi: >=20 > I think this is useful work and did send comments to Fernando offline = as minor nit (as part of comment on another document). Sorry, as I = missed the fact that this was in WGLC. >=20 > Basically, in section 2.2, I think it should be made clear how long = any stale configuration must be "retained" to send in RAs to assure that = information is properly deprecated - which is that it must be retained = until the longest valid lifetime it was ever advertised with has = elapsed. >=20 > The above suggestion is in line with a related discussion for the = draft-gont-6man-slaac-renum document, where perhaps the CPE should cap = the lifetimes it advertises in RAs. Though it may also be something to = consider adding to Section 2.1 of cpe-slaac-renum (i.e., a CPE may cap = the lifetimes advertised in RAs). The current text only says that they = must not be greater than the (remaining) DHCP lifetimes. >=20 > And I also just noticed there is a need to clean up the reference that = still points to the individual submission: >=20 > [I-D.gont-v6ops-slaac-renum] > Gont, F., Zorz, J., and R. Patterson, "Reaction of > Stateless Address Autoconfiguration (SLAAC) to Flash- > Renumbering Events", draft-gont-v6ops-slaac-renum-02 = (work > in progress), February 2020. >=20 > It is somewhat confusing with the 3 documents = (draft-ietf-v6ops-cpe-slaac-renum, draft-ietf-v6ops-slaac-renum, = draft-gont-6man-slaac-renum) as they have similar names. >=20 > - Bernie >=20 > -----Original Message----- > From: v6ops On Behalf Of Fred Baker > Sent: Friday, April 3, 2020 11:55 AM > To: IPv6 Operations > Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum >=20 > Yes. In short, we had several people say that the topic was something = they wanted to kick around, so we made it a working group draft. Ron and = I are now looking for working group comments on it, in the absence of = which we can't tell the IESG there is support. Are there any opinions on = this document? >=20 >> On Apr 2, 2020, at 11:49 AM, Fernando Gont = wrote: >>=20 >> Hello, folks, >>=20 >> Long time no hear! I hope all of you and your beloved ones are fine = in these crazy times. >>=20 >> v6ops is WGLC'ing one of the documents = (https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-01) we = have authored to improve the reaction of SLAAC to renumbering events. = This document contains recommendations for Customer Edge Routers. >>=20 >> For background, you may want to consult:=20 >> https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01 >>=20 >> If you have any comments/feedback, please do let us know. If = possible,=20 >> on the v6ops list (https://www.ietf.org/mailman/listinfo/v6ops) >>=20 >> Thanks! >>=20 >> Cheers, >> Fernando >>=20 >>=20 >>=20 >>=20 >> -------- Forwarded Message -------- >> Subject: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum >> Date: Mon, 30 Mar 2020 15:47:14 +0000 >> From: Ron Bonica >> To: v6ops@ietf.org >>=20 >>=20 >>=20 >> Folks, >>=20 >> This message initiates a WG Last Call on = draft-ietf-v6ops-cpe-slaac-renum. >>=20 >> Please submit comments by April 13, 2020. >>=20 >> Fred and Ron >>=20 >>=20 >> Juniper Business Use Only >>=20 >>=20 >>=20 >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP = Fingerprint:=20 >> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >>=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 From nobody Fri Apr 3 13:23:42 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588653A0A04 for ; Fri, 3 Apr 2020 13:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZXI6rq6dax1 for ; Fri, 3 Apr 2020 13:23:39 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6A33A09F9 for ; Fri, 3 Apr 2020 13:23:39 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id v13so3524540pjb.0 for ; Fri, 03 Apr 2020 13:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Y+X0Xn2MKJSmx8A0EWGixbBeq+xUyuzNW4eLYYzX/Zk=; b=EMf6RBVyqXtqfPAr5wOjTseKoRKh43xQcvamJIx0osZRtEaGcTGdoSxmxmCvNtFJkD 2nlSu4OxjO2/415p8hKgsFFLB1uENqe+Eab8grzIw5bSd6BbsXkqUsvTrJJ92gHXAMJw M8HloflQT6RYZavwEjU/RifNXpKtaKeey4jrS563RiyaiwcVNvVrp2gyDjTK/e5yC03B L2Z05VA5r7YibJtcs/I4iGkDQ6KrKn94iTNp9kzrszuQL8JE/uLLsB2NWbjBSB9/pLMX u5Yfb7r8hxgIsRtAfAN+foI6lx8dHrkwThnedA3btvj0N/D/R7j5NZTsP7JPDRsQC7r0 AojA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y+X0Xn2MKJSmx8A0EWGixbBeq+xUyuzNW4eLYYzX/Zk=; b=ZYKfxTQbx2A/WKLm6tYjv3Frit4EeZNlTl7rSdd9FRIH3eZR705xIOFNbHNhiUsWtm 7VoJbK+q6qSy+nYT+qxR7wVUZ0Ey0qL6QDdrxT87CC914Tk5xpMe+MlTb0YWdMowq5x1 E6rSWVAT1aF55BKSP8mg58lULmMYJTq5ka/WLfI4EtMRRlaq1iyOcIteTdkqGFvOvpVC kP9MkmQvOnCv+ePMLaoHKBi22N9AnswpMkkfTk6B+WrCfNSVexSb5eEyL6UzNYh86PL9 IyBY3SGYt9O3wB2/SKsPu8NSbD/B/1NRreq+eX+7Tw8smYtsdp3GF77P79lrn2i1BUGU 4rWw== X-Gm-Message-State: AGi0PubbUVjVg984YigyPY0pBNSVvL27QnnwIM3Al1tNi+a/fg1SeoZe C834FGyVcvrQiYkHKfF1Xb6qxuXd X-Google-Smtp-Source: APiQypJOtvDRAtSPI2k6bB0h9sbu5znRxGcVGQraTriAm1ONl34L7+LPsW/8Q3dK+ElvHj/efIvjfQ== X-Received: by 2002:a17:902:aa44:: with SMTP id c4mr10075713plr.56.1585945419040; Fri, 03 Apr 2020 13:23:39 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id s76sm5735635pgc.64.2020.04.03.13.23.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2020 13:23:38 -0700 (PDT) To: Fred Baker , IPv6 Operations References: <0D10FD07-A26A-4456-B358-CE1D9A454777@gmail.com> From: Brian E Carpenter Message-ID: Date: Sat, 4 Apr 2020 09:23:34 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <0D10FD07-A26A-4456-B358-CE1D9A454777@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2020 20:23:41 -0000 Hmm. I tend to think of WGLC as last call for objections, when a WG document has been in discussion for a while. But if you're looking for support, yes, this is very useful and I have no further technical comments. Regards Brian On 04-Apr-20 04:54, Fred Baker wrote: > Yes. In short, we had several people say that the topic was something they wanted to kick around, so we made it a working group draft. Ron and I are now looking for working group comments on it, in the absence of which we can't tell the IESG there is support. Are there any opinions on this document? > >> On Apr 2, 2020, at 11:49 AM, Fernando Gont wrote: >> >> Hello, folks, >> >> Long time no hear! I hope all of you and your beloved ones are fine in these crazy times. >> >> v6ops is WGLC'ing one of the documents (https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-01) we have authored to improve the reaction of SLAAC to renumbering events. This document contains recommendations for Customer Edge Routers. >> >> For background, you may want to consult: https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01 >> >> If you have any comments/feedback, please do let us know. If possible, on the v6ops list (https://www.ietf.org/mailman/listinfo/v6ops) >> >> Thanks! >> >> Cheers, >> Fernando >> >> >> >> >> -------- Forwarded Message -------- >> Subject: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum >> Date: Mon, 30 Mar 2020 15:47:14 +0000 >> From: Ron Bonica >> To: v6ops@ietf.org >> >> >> >> Folks, >> >> This message initiates a WG Last Call on draft-ietf-v6ops-cpe-slaac-renum. >> >> Please submit comments by April 13, 2020. >> >> Fred and Ron >> >> >> Juniper Business Use Only >> >> >> >> -- >> 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 > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sat Apr 4 19:03:57 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B715C3A1071 for ; Sat, 4 Apr 2020 19:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 HMVo6tr3FJWH for ; Sat, 4 Apr 2020 19:03:52 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF733A1070 for ; Sat, 4 Apr 2020 19:03:52 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 761FF80589; Sun, 5 Apr 2020 04:03:49 +0200 (CEST) To: "Bernie Volz (volz)" , Fred Baker , IPv6 Operations References: <0D10FD07-A26A-4456-B358-CE1D9A454777@gmail.com> From: Fernando Gont Message-ID: Date: Sat, 4 Apr 2020 22:46:51 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Apr 2020 02:03:56 -0000 Hello, Bernie, Thanks for your feedback! In-line.... On 3/4/20 13:43, Bernie Volz (volz) wrote: [..]> > Basically, in section 2.2, I think it should be made clear how long any stale configuration must be "retained" to send in RAs to assure that information is properly deprecated - which is that it must be retained until the longest valid lifetime it was ever advertised with has elapsed. I've added this note as a rationale: RATIONALE: Hosts on the local network may employ addresses configured for the previously advertised prefixes for at most the "Valid Lifetime" of the corresponding PIO of the last received Router Advertisement message. Since Router Advertisement messages may be lost or fail to be received for various reasons, Customer Edge Routers need to try to deprecate stale prefixes for a period of time equal to the "Valid Lifetime" of the PIO employed when originally advertising the prefix. I wonder if this document should say something about the actual lifetime values, as in: "CPE Routers should consider employing "Preferred Lifetime" and "Valid Lifetime" values for the prefixes they advertise that are shorter than the recommended default values in RFC4861. If shorter lifetimes are employed, they SHOULD be selected according to the criteria in Section 2.1 of this document, and the recommendations in RFC7772." Thoughts? > The above suggestion is in line with a related discussion for the draft-gont-6man-slaac-renum document, where perhaps the CPE should cap the lifetimes it advertises in RAs. Though it may also be something to consider adding to Section 2.1 of cpe-slaac-renum (i.e., a CPE may cap the lifetimes advertised in RAs). The current text only says that they must not be greater than the (remaining) DHCP lifetimes. Any thoughts about the proposed text above? > And I also just noticed there is a need to clean up the reference that still points to the individual submission: > > [I-D.gont-v6ops-slaac-renum] > Gont, F., Zorz, J., and R. Patterson, "Reaction of > Stateless Address Autoconfiguration (SLAAC) to Flash- > Renumbering Events", draft-gont-v6ops-slaac-renum-02 (work > in progress), February 2020. You mean to remove the reference since so far it's still an individual submission? (If so, that's fine for me). > It is somewhat confusing with the 3 documents (draft-ietf-v6ops-cpe-slaac-renum, draft-ietf-v6ops-slaac-renum, draft-gont-6man-slaac-renum) as they have similar names. I completely agree. In retrospective, this was a very bad choice on my side. :-( 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 Sun Apr 5 05:51:43 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10ED73A080E for ; Sun, 5 Apr 2020 05:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=EZBiKepn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NEU6cD6X Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONV8nYbAzHNR for ; Sun, 5 Apr 2020 05:51:37 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5443A080B for ; Sun, 5 Apr 2020 05:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4656; q=dns/txt; s=iport; t=1586091097; x=1587300697; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ix/GdSNoA8e2P45dHPezrhi7E9ecJy2yGfeUSpBisx4=; b=EZBiKepn8lQ1kbDvrxfRMEbiTDDa3W+x0wPXPG2CpqGniXk7fiZniaMC sQA38yJykBUJOqbWA0Bi9K6ZYM/YBycSIHFCNEfluZbQlcDJZ35wkjbFj Az60GAhNHZ1MgiLwnbiy7lYVFoX//H5p4ESsKKUkc/IHZP/JyfyktRDkQ Q=; IronPort-PHdr: =?us-ascii?q?9a23=3ARzbgLBAwPj+/CZuQl1xeUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qgw3kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMdRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFP8KOzCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChBQCW04le/5ldJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVFAFgUQgBAsqCoQRg0UDimaCOiWYHoJSA1QKAQEBDAEBLQI?= =?us-ascii?q?EAQGERAIXgi8kOBMCAwEBCwEBBQEBAQIBBQRthVYMhXABAQEBAgESEREMAQE?= =?us-ascii?q?3AQQLAgEIGAICJgICAjAVEAEBBA4FIoMEgkwDDiABpBYCgTmIYnWBMoJ/AQE?= =?us-ascii?q?FgkWCehiCDQmBDiqFIw2HAxqCAIE4DBCCTT6HYDKCLJEEoB4Kgj2XKh2cAot?= =?us-ascii?q?AoBwCBAIEBQIOAQEFgWkigVdwFWUBgj5QGA2OHYNzilV0gSmMcgGBDwEB?= X-IronPort-AV: E=Sophos;i="5.72,347,1580774400"; d="scan'208";a="458686170" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Apr 2020 12:51:36 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 035Cpa1M023695 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 5 Apr 2020 12:51:36 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 5 Apr 2020 07:51:36 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 5 Apr 2020 08:51:34 -0400 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 5 Apr 2020 07:51:34 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WqLsoU1SH3f5QIJT2C3NO7owHaQCJ3ONmY7RED4cd4m8Cp5cTtis8LwmAXbVGhZDjVFpYXUxn9hBNfyM6xW3/xgKXI3U0zJTPhEaSUln+lzqU2QiKWDU6W944sVx0SoVyeywGc9t5XTRkJsmAWo/ExqYmuF2NifakLqCe6AshLlFnaxLx9x/AzaFV2gmukW5y7IN1gqZPi9RJkxzOk5SNrvroEW+0ZYDEN3OwzxU8Je2g5PJk/YNlObs5YzgibJ1JAJcc3LjCUVLDVC67BXji2ccycDGL8eub0mNDJteMEv2SeHp4LVSXy6v4T4Hppox9lRNcEuKRLkUeQCTCgBaTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ix/GdSNoA8e2P45dHPezrhi7E9ecJy2yGfeUSpBisx4=; b=BTCtDOkXEYZz+ZWkYtVmIZhQkDzkihU0/9HQqbEt3qU7RwiTI/G4jywHrtGkzZrNI20JOMz6/j/9Ny5xtnc1vabltftGuaUhFza3s8al+/y1mk84PvwsebWncUvw8WI4gGXZei2NVWcl04Zub2q0vRjM0LcdlRE01KN8PfJmY8BBuNT/9eIt8lUqG3DOkHFxh2YhdKbggNWV6M4sxv4xZG5MLRUX8uFTOxzJzmY1u0UuUA3Cv3cgL9Ig1QSuA2tDMdr9zLctw+j/exbL6S46Jt64ra+L7eIRtff9183Nfy1OwmvEm7ALXpOAlcQMwh1qJlCKQ94Wow98s+t7MGYmoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ix/GdSNoA8e2P45dHPezrhi7E9ecJy2yGfeUSpBisx4=; b=NEU6cD6XVf36AxAyfzJluOxiLlpqck8Ds9NFR5BDDWoOScHClfuOZ6IeTnRZadRKVyOj5UC3oARDM6Bct3n1cLGmO9yTXWjSpTjJPAoLl+b8Vt1qtCEffKyl/VRpRXran4PDT/ZM0RXdQC4zNfAOsznkk1U5C4J0MakfJljTb4Q= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2787.namprd11.prod.outlook.com (2603:10b6:406:b4::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Sun, 5 Apr 2020 12:51:33 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Sun, 5 Apr 2020 12:51:33 +0000 From: "Bernie Volz (volz)" To: Fernando Gont CC: Fred Baker , IPv6 Operations Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdYGqnrRGOoD4f0yRz2uh9FnYboxrQDJdGHbAADG6AAARirjgAAXNuYx Date: Sun, 5 Apr 2020 12:51:33 +0000 Message-ID: <5EEACB01-2B33-4262-B77D-CD96AD983F74@cisco.com> References: <0D10FD07-A26A-4456-B358-CE1D9A454777@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [24.233.121.124] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f5136d5-57e1-40e9-ff39-08d7d96011c9 x-ms-traffictypediagnostic: BN7PR11MB2787: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(366004)(346002)(396003)(6486002)(186003)(66476007)(64756008)(76116006)(66946007)(478600001)(66556008)(26005)(6512007)(91956017)(66574012)(66446008)(81156014)(81166006)(5660300002)(33656002)(53546011)(2616005)(8676002)(6506007)(86362001)(54906003)(71200400001)(4326008)(316002)(36756003)(6916009)(2906002)(8936002)(401264004); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qyqJIP/AWVs9e6Yum4NZtCl3aJNFc2WwXZNv+j7e9Z4D2CHkVtoLOP5nBzh0kA5I1kko4uUe+baIc4rG0mLWc2MXvrd5V4/LFjRm4eYm9rEj81+71wp5uxTPKupZPaOMZ1gPciLb+r6OrynFKq3NsHTusPDfuKxLozgLgd9nfNFGDZArwh4J/U8wqeiRrMvQtahhInxNHBVyuZWjCdGpYO5pMJsRBLi2c6OKU0TOrhvNvhwFve2L1AXXAMjHBgBPdiP96ZuhqXN7iBrQTXKG+duQaai1q4uF1y3Rfhwka/0hvUZ2fKtrL0UkFaqtUllLaAV1w4gs8+4cpkSCWiJY7+OVsz7LI4MUCBf5LX5viWCDUI64h1NEaivwhkCbQ6k0DMA6N8kcD8K1nN4IB/oM/5XmvU7o/kCAEAQ5u4pNl8pDFrWX7zzHCE3RC/VYfp1ucg3ZnCNU6NlalPkucz1N/0RYhEOIMA1pxtGYywFmBFF4OI5nTUQYI69zbaP3+hkx x-ms-exchange-antispam-messagedata: dMQ+Fzdq6cEC+bisUH900yVR/iIf3gPhTbllU7itK8UAcf1P+OUKMACh29tRrwjPZEvl6p0n1WQOt7RMpNJEjkdrHSQsm4zwN4aITAjZePHuIgu7wqtdxSTqWqjScT5Pb8gPMshhCo1CS92WlaRcDQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8f5136d5-57e1-40e9-ff39-08d7d96011c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2020 12:51:33.3943 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ECxlM+7YyoF04/1Khz/KRX2/bpo4S22IDil/W4KfyVA2tj3EDJCy4yapgLUsopzR X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2787 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Apr 2020 12:51:40 -0000 SGkgLi4uIGlubGluZSBiZWxvdyAoQlY+KS4NCg0KLSBCZXJuaWUNCg0KPiBPbiBBcHIgNCwgMjAy MCwgYXQgMTA6MDQgUE0sIEZlcm5hbmRvIEdvbnQgPGZlcm5hbmRvQGdvbnQuY29tLmFyPiB3cm90 ZToNCj4gDQo+IO+7v0hlbGxvLCBCZXJuaWUsDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgZmVlZGJh Y2shIEluLWxpbmUuLi4uDQo+IA0KPiBPbiAzLzQvMjAgMTM6NDMsIEJlcm5pZSBWb2x6ICh2b2x6 KSB3cm90ZToNCj4gWy4uXT4NCj4+IEJhc2ljYWxseSwgaW4gc2VjdGlvbiAyLjIsIEkgdGhpbmsg aXQgc2hvdWxkIGJlIG1hZGUgY2xlYXIgaG93IGxvbmcgYW55IHN0YWxlIGNvbmZpZ3VyYXRpb24g bXVzdCBiZSAicmV0YWluZWQiIHRvIHNlbmQgaW4gUkFzIHRvIGFzc3VyZSB0aGF0IGluZm9ybWF0 aW9uIGlzIHByb3Blcmx5IGRlcHJlY2F0ZWQgLSB3aGljaCBpcyB0aGF0IGl0IG11c3QgYmUgcmV0 YWluZWQgdW50aWwgdGhlIGxvbmdlc3QgdmFsaWQgbGlmZXRpbWUgaXQgd2FzIGV2ZXIgYWR2ZXJ0 aXNlZCB3aXRoIGhhcyBlbGFwc2VkLg0KPiANCj4gSSd2ZSBhZGRlZCB0aGlzIG5vdGUgYXMgYSBy YXRpb25hbGU6DQo+IA0KPiBSQVRJT05BTEU6DQo+IEhvc3RzIG9uIHRoZSBsb2NhbCBuZXR3b3Jr IG1heSBlbXBsb3kgYWRkcmVzc2VzIGNvbmZpZ3VyZWQgZm9yIHRoZSBwcmV2aW91c2x5IGFkdmVy dGlzZWQgcHJlZml4ZXMgZm9yIGF0IG1vc3QgdGhlICJWYWxpZCBMaWZldGltZSIgb2YgdGhlIGNv cnJlc3BvbmRpbmcgUElPIG9mIHRoZSBsYXN0IHJlY2VpdmVkIFJvdXRlciBBZHZlcnRpc2VtZW50 IG1lc3NhZ2UuIFNpbmNlIFJvdXRlciBBZHZlcnRpc2VtZW50IG1lc3NhZ2VzIG1heSBiZSBsb3N0 IG9yIGZhaWwgdG8gYmUgcmVjZWl2ZWQgZm9yIHZhcmlvdXMgcmVhc29ucywgQ3VzdG9tZXIgRWRn ZSBSb3V0ZXJzIG5lZWQgdG8gdHJ5IHRvIGRlcHJlY2F0ZSBzdGFsZSBwcmVmaXhlcyBmb3IgYSBw ZXJpb2Qgb2YgdGltZSBlcXVhbCB0byB0aGUgIlZhbGlkIExpZmV0aW1lIiBvZiB0aGUgUElPIGVt cGxveWVkIHdoZW4gb3JpZ2luYWxseSBhZHZlcnRpc2luZyB0aGUgcHJlZml4Lg0KPiANCkJWPiBz ZWVtcyBnb29kDQo+IA0KPiBJIHdvbmRlciBpZiB0aGlzIGRvY3VtZW50IHNob3VsZCBzYXkgc29t ZXRoaW5nIGFib3V0IHRoZSBhY3R1YWwgbGlmZXRpbWUgdmFsdWVzLCBhcyBpbjoNCj4gDQo+ICJD UEUgUm91dGVycyBzaG91bGQgY29uc2lkZXIgZW1wbG95aW5nICJQcmVmZXJyZWQgTGlmZXRpbWUi IGFuZCAiVmFsaWQgTGlmZXRpbWUiIHZhbHVlcyBmb3IgdGhlIHByZWZpeGVzIHRoZXkgYWR2ZXJ0 aXNlIHRoYXQgYXJlIHNob3J0ZXIgdGhhbiB0aGUgcmVjb21tZW5kZWQgZGVmYXVsdCB2YWx1ZXMg aW4gUkZDNDg2MS4gSWYgc2hvcnRlciBsaWZldGltZXMgYXJlIGVtcGxveWVkLCB0aGV5IFNIT1VM RCBiZSBzZWxlY3RlZCBhY2NvcmRpbmcgdG8gdGhlIGNyaXRlcmlhIGluIFNlY3Rpb24gMi4xIG9m IHRoaXMgZG9jdW1lbnQsIGFuZCB0aGUgcmVjb21tZW5kYXRpb25zIGluIFJGQzc3NzIuIg0KPiAN CkJWPiBwcm9iYWJseSBwcmVtYXR1cmUgdW50aWwgZGlzY3Vzc2lvbnMgYWJvdXQgdGhpcyBzZXR0 bGUgZG93bj8gQWxzbywgbm90IHN1cmUgd2hpY2ggcHJlZml4ZXMgdGhpcyByZWZlcnMgdG8g4oCU IGRoY3Agb2J0YWluZWQgb25lcyBsaWtlbHkgdXNlIChyZW1haW5pbmcpIGxpZmV0aW1lcyBmcm9t IGRoY3AuIEFuZCBpZiBkaGNwLCBhcmUgeW91IHRyeWluZyB0byBpbmRpY2F0ZSB0aGF0IHNob3J0 ZXIgb2YgZGhjcCByZW1haW5pbmcgYW5kIGRlZmF1bHRzIGJlIHVzZWQ/DQo+IA0KPiBUaG91Z2h0 cz8NCj4gDQo+IA0KPiANCj4+IFRoZSBhYm92ZSBzdWdnZXN0aW9uIGlzIGluIGxpbmUgd2l0aCBh IHJlbGF0ZWQgZGlzY3Vzc2lvbiBmb3IgdGhlIGRyYWZ0LWdvbnQtNm1hbi1zbGFhYy1yZW51bSBk b2N1bWVudCwgd2hlcmUgcGVyaGFwcyB0aGUgQ1BFIHNob3VsZCBjYXAgdGhlIGxpZmV0aW1lcyBp dCBhZHZlcnRpc2VzIGluIFJBcy4gVGhvdWdoIGl0IG1heSBhbHNvIGJlIHNvbWV0aGluZyB0byBj b25zaWRlciBhZGRpbmcgdG8gU2VjdGlvbiAyLjEgb2YgY3BlLXNsYWFjLXJlbnVtIChpLmUuLCBh IENQRSBtYXkgY2FwIHRoZSBsaWZldGltZXMgYWR2ZXJ0aXNlZCBpbiBSQXMpLiBUaGUgY3VycmVu dCB0ZXh0IG9ubHkgc2F5cyB0aGF0IHRoZXkgbXVzdCBub3QgYmUgZ3JlYXRlciB0aGFuIHRoZSAo cmVtYWluaW5nKSBESENQIGxpZmV0aW1lcy4NCj4gDQo+IEFueSB0aG91Z2h0cyBhYm91dCB0aGUg cHJvcG9zZWQgdGV4dCBhYm92ZT8NCj4gDQo+IA0KPiANCj4+IEFuZCBJIGFsc28ganVzdCBub3Rp Y2VkIHRoZXJlIGlzIGEgbmVlZCB0byBjbGVhbiB1cCB0aGUgcmVmZXJlbmNlIHRoYXQgc3RpbGwg cG9pbnRzIHRvIHRoZSBpbmRpdmlkdWFsIHN1Ym1pc3Npb246DQo+PiAgICBbSS1ELmdvbnQtdjZv cHMtc2xhYWMtcmVudW1dDQo+PiAgICAgICAgICAgICAgIEdvbnQsIEYuLCBab3J6LCBKLiwgYW5k IFIuIFBhdHRlcnNvbiwgIlJlYWN0aW9uIG9mDQo+PiAgICAgICAgICAgICAgIFN0YXRlbGVzcyBB ZGRyZXNzIEF1dG9jb25maWd1cmF0aW9uIChTTEFBQykgdG8gRmxhc2gtDQo+PiAgICAgICAgICAg ICAgIFJlbnVtYmVyaW5nIEV2ZW50cyIsIGRyYWZ0LWdvbnQtdjZvcHMtc2xhYWMtcmVudW0tMDIg KHdvcmsNCj4+ICAgICAgICAgICAgICAgaW4gcHJvZ3Jlc3MpLCBGZWJydWFyeSAyMDIwLg0KPiAN Cj4gWW91IG1lYW4gdG8gcmVtb3ZlIHRoZSByZWZlcmVuY2Ugc2luY2Ugc28gZmFyIGl0J3Mgc3Rp bGwgYW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uPyAgKElmIHNvLCB0aGF0J3MgZmluZSBmb3IgbWUp Lg0KPiANCj4gDQpCVj4gVGhlIHY2b3BzIGRvY3VtZW50IGlzIG5vdyBkcmFmdC1pZXRmPyA2bWFu IG9uZSBpcyBzdGlsbCBpbmRpdmlkdWFsIHN1Ym1pc3Npb24uDQo+IA0KPj4gSXQgaXMgc29tZXdo YXQgY29uZnVzaW5nIHdpdGggdGhlIDMgZG9jdW1lbnRzIChkcmFmdC1pZXRmLXY2b3BzLWNwZS1z bGFhYy1yZW51bSwgZHJhZnQtaWV0Zi12Nm9wcy1zbGFhYy1yZW51bSwgZHJhZnQtZ29udC02bWFu LXNsYWFjLXJlbnVtKSBhcyB0aGV5IGhhdmUgc2ltaWxhciBuYW1lcy4NCj4gDQo+IEkgY29tcGxl dGVseSBhZ3JlZS4gSW4gcmV0cm9zcGVjdGl2ZSwgdGhpcyB3YXMgYSB2ZXJ5IGJhZCBjaG9pY2Ug b24gbXkgc2lkZS4gOi0oDQo+IA0KPiBUaGFua3MhDQo+IA0KPiBDaGVlcnMsDQo+IC0tIA0KPiBG ZXJuYW5kbyBHb250DQo+IGUtbWFpbDogZmVybmFuZG9AZ29udC5jb20uYXIgfHwgZmdvbnRAc2k2 bmV0d29ya3MuY29tDQo+IFBHUCBGaW5nZXJwcmludDogNzgwOSA4NEY1IDMyMkUgNDVDNyBGMUM5 IDM5NDUgOTZFRSBBOUVGIEQwNzYgRkZGMQ0KPiANCj4gDQo+IA0K From nobody Sun Apr 5 07:22:39 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D8D3A0A8C for ; Sun, 5 Apr 2020 07:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5BwYHfwYTsD for ; Sun, 5 Apr 2020 07:22:36 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6278C3A0A8E for ; Sun, 5 Apr 2020 07:22:35 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 3A82680E4B; Sun, 5 Apr 2020 16:22:31 +0200 (CEST) To: "Bernie Volz (volz)" , Fernando Gont Cc: IPv6 Operations References: <0D10FD07-A26A-4456-B358-CE1D9A454777@gmail.com> <5EEACB01-2B33-4262-B77D-CD96AD983F74@cisco.com> From: Fernando Gont Message-ID: Date: Sun, 5 Apr 2020 10:04:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <5EEACB01-2B33-4262-B77D-CD96AD983F74@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Apr 2020 14:22:39 -0000 Hi, Bernie, On 5/4/20 09:51, Bernie Volz (volz) wrote: [...] >> >> On 3/4/20 13:43, Bernie Volz (volz) wrote: >> [..]> >>> Basically, in section 2.2, I think it should be made clear how long any stale configuration must be "retained" to send in RAs to assure that information is properly deprecated - which is that it must be retained until the longest valid lifetime it was ever advertised with has elapsed. >> >> I've added this note as a rationale: >> >> RATIONALE: >> Hosts on the local network may employ addresses configured for the previously advertised prefixes for at most the "Valid Lifetime" of the corresponding PIO of the last received Router Advertisement message. Since Router Advertisement messages may be lost or fail to be received for various reasons, Customer Edge Routers need to try to deprecate stale prefixes for a period of time equal to the "Valid Lifetime" of the PIO employed when originally advertising the prefix. >> > BV> seems good OK, will add this to the next rev. >> I wonder if this document should say something about the actual lifetime values, as in: >> >> "CPE Routers should consider employing "Preferred Lifetime" and "Valid Lifetime" values for the prefixes they advertise that are shorter than the recommended default values in RFC4861. If shorter lifetimes are employed, they SHOULD be selected according to the criteria in Section 2.1 of this document, and the recommendations in RFC7772." >> > BV> probably premature until discussions about this settle down? Certainly, I wasn't thinking about recommending any specific value, but rather to suggest that they may consider using values other than the default ones. (i.e., if they have the knobs, they should be in a position to select something that works). > Also, not sure which prefixes this refers to — dhcp obtained ones likely use (remaining) lifetimes from dhcp. And if dhcp, are you trying to indicate > that shorter of dhcp remaining and defaults be used? What I have in mind is this: Lets say that, at time t0, you get leased a prefix for one month. One option is to advertise the prefix via a PIO with a lifetime of one month (and reducing lifetime over time). Another option is to advertise the prefix on the local network with a lifetime of, say, one hour. You'd keep advertising the prefix as such, until you get to t0 + 1 month - 1 hour. At which point you'd be decreasing the lifetimes of your RAs. The difference here is that if you use the complete lifetime of the prefix lease, you'd probably advertise an insanely long value that is harder to recover from. Whereas if you never use lifetimes longer than, say, one hour, in the presence of a router crash hosts would use stale information for, at most, one hour. i.e. the lifetimes in RA packets do not need to reflect the total lifetime of the prefix lease. >>> The above suggestion is in line with a related discussion for the draft-gont-6man-slaac-renum document, where perhaps the CPE should cap the lifetimes it advertises in RAs. Though it may also be something to consider adding to Section 2.1 of cpe-slaac-renum (i.e., a CPE may cap the lifetimes advertised in RAs). The current text only says that they must not be greater than the (remaining) DHCP lifetimes. >> >> Any thoughts about the proposed text above? >> >> >> >>> And I also just noticed there is a need to clean up the reference that still points to the individual submission: >>> [I-D.gont-v6ops-slaac-renum] >>> Gont, F., Zorz, J., and R. Patterson, "Reaction of >>> Stateless Address Autoconfiguration (SLAAC) to Flash- >>> Renumbering Events", draft-gont-v6ops-slaac-renum-02 (work >>> in progress), February 2020. >> >> You mean to remove the reference since so far it's still an individual submission? (If so, that's fine for me). >> >> > BV> The v6ops document is now draft-ietf? 6man one is still individual submission. Sorry, my bad. I think you meant that we should simply replace the reference to individual submission with the draft-ietf version. Is that correct? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Apr 5 12:11:29 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CDD3A083F for ; Sun, 5 Apr 2020 12:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qwCROpbjWdF for ; Sun, 5 Apr 2020 12:11:24 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80743A083D for ; Sun, 5 Apr 2020 12:11:24 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jLAfx-0000LNC; Sun, 5 Apr 2020 21:11:21 +0200 Message-Id: To: v6ops@ietf.org Cc: Fernando Gont From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com Date: Sun, 05 Apr 2020 21:11:20 +0200 Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Apr 2020 19:11:26 -0000 Hi, I have two comments on this draft: 1) Section 2.1. (Interface Between DHCPv6-PD and SLAAC) It would be nice have a text like 'The router MAY provide an option where the user can override the valid and preferred lifetimes.' Case in point, my ISP gives me a more or less fixed IPv6 prefix. However, for technical reasons customers have to run DHCPv6-PD. So this leave the user with no way to manually configre the lifetimes. 2) Based on the 6man discussion, I'm missing a section where overly long lifetime values in DHCPv6-PD are reduced by the router. From nobody Sun Apr 5 13:26:04 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FFC3A0C23 for ; Sun, 5 Apr 2020 13:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnG8xvPWyyUZ for ; Sun, 5 Apr 2020 13:24:51 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8933A0BDD for ; Sun, 5 Apr 2020 13:24:50 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 97F3080E4A; Sun, 5 Apr 2020 22:24:46 +0200 (CEST) To: Philip Homburg , v6ops@ietf.org References: From: Fernando Gont Message-ID: Date: Sun, 5 Apr 2020 17:23:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Apr 2020 20:25:03 -0000 Hello, Philip, On 5/4/20 16:11, Philip Homburg wrote: > Hi, > > I have two comments on this draft: > 1) Section 2.1. (Interface Between DHCPv6-PD and SLAAC) > > It would be nice have a text like > 'The router MAY provide an option where the user can override the valid and > preferred lifetimes.' > > Case in point, my ISP gives me a more or less fixed IPv6 prefix. However, > for technical reasons customers have to run DHCPv6-PD. So this leave the > user with no way to manually configre the lifetimes. You mean the router simply copies the lifetimes from dhcpve-pd? > 2) Based on the 6man discussion, I'm missing a section where overly long > lifetime values in DHCPv6-PD are reduced by the router. PUtting together the text I had suggested to Bernie, and some additional notes, how about this: ---- cut here ---- The Valid Lifetime and Preferred Lifetime of PIOs have direct impact on two different aspects: * The amount of time hosts may end up employing stale network configuration information (see [draft-ietf-v6ops-slaac-renum]). * The amount of time a Customer Edge router would need to persist trying to deprecate stale network configuration information (to handle cases where nodes miss Router Advertisements and thus still consider the stale information as valid). As a result, a CPE Routers should consider overriding the default "Preferred Lifetime" and "Valid Lifetime" values from [RFC4861], and employ shorted values to mitigate the aforementioned effect. In such case, the selected values should always follow the requirement from Section 2.1 of this document, and the recommendations in RFC7772. We note that a CPE Router need not directly reflect possibly long DHCPv-PD lease times in the corresponding Router Advertisements sent on the local network. Instead, shorter values may be used for the Router Advertisement messages which successively extend the prefix lifetimes on the local network, without ever spanning such lifetime past the DCHPv6-PD lease time. --- cut here ---- That's one option, without numbers. If we wanted to suggest numbres, I guess there could be to options: 1) Something like: PL: Router Lifetime, V:= 1 day -- which seems to be a very conservative choice that everyone seems to support, or., 2) Point to draft-gont-6man-slaac-renum Thoughts? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 6 03:54:52 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8F03A0E29 for ; Mon, 6 Apr 2020 03:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hayiZOTi1Y66 for ; Mon, 6 Apr 2020 03:54:45 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80108.outbound.protection.outlook.com [40.107.8.108]) (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 9E7403A0E22 for ; Mon, 6 Apr 2020 03:54:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nLWcQ1Q7CmkcddPuuvuoMmOwlFRhdtA//XsuwF3F0MgKYvQEFcL43PZEXCyXVeR0zlDl61AprCEDzLqGxduEhIvLNsy/XEJ1dFM3Khqffa4UK3cSvmBykV5UzQV7wT0ZlJm1q70FU/NoNU4qqbHZUOlubgPXsQc4U4oKqiJJH+tC8uM7ZgKeH6bT+UHu5ifCTnYsQYwBtrn2oUNPS6/VSs+RLUssUgam2LkdUxicghvcP1X8nILfMXxRWS+uJQI7Mnvz59oa7JXWazSVV39OfcAE7YGuN3lF1E/FhRvwfRyKPzBzh9JlltKKQBZCU63ohGLp/5g4RdhUtY9Dd/SjUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BC44fpFjjLjxK/Gz1YSBBD1+N6lo3SBN1/NkmhTY5o0=; b=ljNgX96j5sHmuGh/6B+ymI7H5+CIJSJpGCgfV8jwmK38k2b8Ym/y2R7YkNWnIb20rNvITX4LyUXhEVgbIB746wzQtkyPQiLwyRlEGu+UZ8he8Dv18ODqWW1DwFFJLlXwjim/ZOzCPsYW3QmB4BSs7vuxSEEAuz/r/wdWpgOa9cQPzZHGSaQLBhcOciYwUgFMMjLtSQkvhs6NFz56y3Tre8R9ZtAsxIC1P1dcYna0RMZaVrvvEpyfMDWdSFQ1eTG1NZ/xLeDA+C8a6SPj0iyB93biDaNMSlBlkSaGnjbrslalnzIgKnfeftaBoaAK8V8sqb1TbC0lxNvAxev37FwXSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BC44fpFjjLjxK/Gz1YSBBD1+N6lo3SBN1/NkmhTY5o0=; b=x3qOKplpCpTLWcQlhnV5pe4CgToU3L6+C2+gUQ9X+blbbbX56sQMrr8wKF9azTKWBCRZZ9IZ62c5WXBuILAHF9CAh3ea+v2j6cKEqgJnfvLb4c6hkHDJJkaTnSGw8rEvN9dgV6IxjmrZRagZ6e29WpUzYyEjHu5v26a/6GKpPFM= Received: from DB7PR07MB5657.eurprd07.prod.outlook.com (20.178.85.222) by DB7PR07MB5705.eurprd07.prod.outlook.com (20.178.104.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.13; Mon, 6 Apr 2020 10:54:30 +0000 Received: from DB7PR07MB5657.eurprd07.prod.outlook.com ([fe80::a438:bbc9:2ffe:33ee]) by DB7PR07MB5657.eurprd07.prod.outlook.com ([fe80::a438:bbc9:2ffe:33ee%5]) with mapi id 15.20.2900.012; Mon, 6 Apr 2020 10:54:30 +0000 From: tom petch To: Fred Baker , IPv6 Operations Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AQHWCdBFOjpk11c5pkyEuZ5UzxBt2ahr7icn Date: Mon, 6 Apr 2020 10:54:30 +0000 Message-ID: References: , <0D10FD07-A26A-4456-B358-CE1D9A454777@gmail.com> In-Reply-To: <0D10FD07-A26A-4456-B358-CE1D9A454777@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-originating-ip: [81.131.229.19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f7a93327-0437-49b0-bfe7-08d7da18e23a x-ms-traffictypediagnostic: DB7PR07MB5705: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5657.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(136003)(376002)(396003)(346002)(39860400002)(366004)(6506007)(966005)(2906002)(81166006)(81156014)(86362001)(478600001)(8936002)(55016002)(5660300002)(8676002)(316002)(91956017)(52536014)(7696005)(110136005)(26005)(186003)(66946007)(33656002)(71200400001)(76116006)(66446008)(64756008)(66556008)(9686003)(53546011)(66476007); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XX32oGh7/oCcu576J0b6ajgKYuEztfeKa7nk1tyuIsbuUdxGueFYLNrv0Wz5CmiYPAdQvC3MpksoGMi211PEwPwjwcU3KTf0AbtlWXF47T2Zx7DFaupC8zRlKHuivCXR3SflIlvXOxMMXeZvkBN0W0CvDRa6iDkMLRSpq1CWoSHdD8dTb/dEk70vw4FoX7KsGKq3u271Sm38Ie6krz52rwpC/w0wjF1Hsv3kx17nnSqpyBW1qnrTfnTaQFNAHXt64PjjfbVF3KrH4ePnDbF22d3uHj/4EoJyjTOSrLCKO3+8+Le1gnaXVyliu5JkFKGd/huYnuzTPvizFpLu79s+FtsP4eDVmoiP/aZw3TnfI9LN4xi2/bmmECx2/3uUpUSQzF6rLyZnDN7jAxTt+FoibNo4e2MlS1YO6K+vD8PxD4Iop8pfn5u8SmN8kI1asIiqOV+Cv8C9+Bf22x0hjhaRfxUTKvj7LS8GmKNNVC2A+uLc/+jsxWTQzsO8GgLPmWg5cm0YM30SoxH/Ap3pjC0JYg== x-ms-exchange-antispam-messagedata: K/nZScLS/vcIwJPA1Wzmzld+5zOqZLrxX25YxjxLizh0d2T45t4kjfo6AEMMvlhqSgvjDSXFhGgOSMqhq85RT5Lcnbq6umzPqnS3xYxu8mp3ZRjljcJH8J+SX9CX7wCscGhlaphAYM2k97ybe3bJQw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: f7a93327-0437-49b0-bfe7-08d7da18e23a X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 10:54:30.5176 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tAbEsIvJZHq0agJVYibv/b5dvG18YZmKKZzzUXz6ElyA8PwJe9jJcVg/Sazb3snHY35ZltklHjYTt7YPz8jq4Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5705 Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 10:54:48 -0000 Fred,=0A= =0A= tricky. There is a MUST or two with no mention of RFC2119.=0A= =0A= There are references to updated behaviour but no Updates.=0A= =0A= There is an impressive list of Acknowledgements of which I would expect at = least some to have a view, favourable or otherwise.=0A= =0A= 'is based.earlier versions' looks odd=0A= =0A= but at the end of the day, it all looks sensible except that I do not have = the exposure to this and so find it hard to judge especially as this area o= f IPv6 seems to be an endless saga of change and more change and will this = itself be updated again in a few months time? I do not know.=0A= =0A= Tom Petch=0A= ________________________________________=0A= From: v6ops on behalf of Fred Baker =0A= Sent: 03 April 2020 16:54=0A= To: IPv6 Operations=0A= Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum=0A= =0A= Yes. In short, we had several people say that the topic was something they = wanted to kick around, so we made it a working group draft. Ron and I are n= ow looking for working group comments on it, in the absence of which we can= 't tell the IESG there is support. Are there any opinions on this document?= =0A= =0A= > On Apr 2, 2020, at 11:49 AM, Fernando Gont wrote:= =0A= >=0A= > Hello, folks,=0A= >=0A= > Long time no hear! I hope all of you and your beloved ones are fine in th= ese crazy times.=0A= >=0A= > v6ops is WGLC'ing one of the documents (https://tools.ietf.org/html/draft= -ietf-v6ops-cpe-slaac-renum-01) we have authored to improve the reaction of= SLAAC to renumbering events. This document contains recommendations for Cu= stomer Edge Routers.=0A= >=0A= > For background, you may want to consult: https://tools.ietf.org/html/draf= t-ietf-v6ops-slaac-renum-01=0A= >=0A= > If you have any comments/feedback, please do let us know. If possible, on= the v6ops list (https://www.ietf.org/mailman/listinfo/v6ops)=0A= >=0A= > Thanks!=0A= >=0A= > Cheers,=0A= > Fernando=0A= >=0A= >=0A= >=0A= >=0A= > -------- Forwarded Message --------=0A= > Subject: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum=0A= > Date: Mon, 30 Mar 2020 15:47:14 +0000=0A= > From: Ron Bonica =0A= > To: v6ops@ietf.org =0A= >=0A= >=0A= >=0A= > Folks,=0A= >=0A= > This message initiates a WG Last Call on draft-ietf-v6ops-cpe-slaac-renum= .=0A= >=0A= > Please submit comments by April 13, 2020.=0A= >=0A= > Fred and Ron=0A= >=0A= >=0A= > Juniper Business Use Only=0A= >=0A= >=0A= >=0A= > --=0A= > Fernando Gont=0A= > e-mail: fernando@gont.com.ar || fgont@si6networks.com=0A= > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1=0A= >=0A= >=0A= >=0A= > _______________________________________________=0A= > v6ops mailing list=0A= > v6ops@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/v6ops=0A= =0A= From nobody Mon Apr 6 06:30:40 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F50F3A0408 for ; Mon, 6 Apr 2020 05:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=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 gdFkL3UDbHSi for ; Mon, 6 Apr 2020 05:57:12 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451F63A05AC for ; Mon, 6 Apr 2020 05:57:12 -0700 (PDT) Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 508124E11B13; Mon, 6 Apr 2020 12:57:11 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id B421D314AA23; Mon, 6 Apr 2020 14:57:05 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Mon, 6 Apr 2020 14:57:05 +0200 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ron Bonica X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 13:02:31 -0000 > This message initiates a WG Last Call on = draft-ietf-v6ops-cpe-slaac-renum. > =20 > Please submit comments by April 13, 2020. 0) Remove the reference to the individual draft in introduction. 1) the document proposes a workaround for the case where the service = provider does not renumber the network correctly. It would be useful to add a paragraph in the introduction describing the = "correct" procedure. This to ensure that a reader would not be confused = and think this is how the DHCP PD mechanism is intended to work. I don't think there is a reference for that, I'm not sure we have = written down the correct DHCP PD behaviour when doing instant = renumbering? Something like: "A network provider that has to renumber a customer = network, must continue to include the old prefix in DHCP PD messages = with lifetimes set to 0 for a while, to ensure that stale prefix = information can be expired on hosts attached to the network". 2) Rewrite the document as an update to RFC7084. Make the new = requirements as WPD- Ole= From nobody Mon Apr 6 06:31:33 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB9E3A1495 for ; Mon, 6 Apr 2020 06:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 JTTMAPw-4JOx for ; Mon, 6 Apr 2020 06:27:29 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DBA73A110D for ; Mon, 6 Apr 2020 06:20:02 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id x16so14580757ilp.12 for ; Mon, 06 Apr 2020 06:20:02 -0700 (PDT) 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=MT1bHoIF0OExZYidCmoNG8dnURnZSTj6Y78l2edWPoA=; b=JRw18cGyW79xd4MY71DydwKHssnLQxNoqtZ23I62hI9v9It1iZpL4BrLAW9nBJ+Yem o40LEw7o9PDtudLbXgQK5FRCIrIvEleooRvmMQgl/iU3cRMrMUQBYlETFPfGnrupzSxG f0fKVqxqA1rG/9sw1wpIuG5yioYmiLm5QehC6z3eNzoXBw5gRLfagHuZSsnBjnGs1ywS lSSAML5UdQ+j5KO3p36W7Ato2tG3yuJ4g558RZZhyV/QYo97zJGOzSpTP7qeNJG3IoGe Rp4NAbTO04zVXLfxEmNpErfJ6JNgtYG67HUFAETo/gPt3081eqyLabtitHmK9WlDjXtt zfcA== 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=MT1bHoIF0OExZYidCmoNG8dnURnZSTj6Y78l2edWPoA=; b=SOY8WUeBVQH2mIl9G4nUIvBsvu8z6YFivCpXzMimL/noije+MTrl6ResGIEM8rXdXN XkHeVhQ1VWyvEeeSxH93j1pnbSvBHv+HdG5wMs18UnNYLMkWFtCjqoEXPDr0Hjj0aWEB 7W0fsPWvMz+5+PH/macCVMGx3rB40bZ9c4Ol+iPQcN9g8lwxA9I73fE8/+UhtCWoAIdm 6/og2/OErdDKizl94Znjq7mcxwNuPRC+Rqy6nLDuET7D37hDaGKT6oR/Ia4w7MpvVxya lLze/7eGEbnmRYUj+LayFBwRFfuI6MSYYdkVLLOHeL4GzgwwM7VjA59oJ0QC11+A77Zi Fghw== X-Gm-Message-State: AGi0PubglLgo0Xba7vBpodSnQFLLe2xgpYDchBFQlLnUJKsqL27G6Gn5 82edzAiHOpUHDHVUULFcOd0AmxMRle1TWay3ldlbGA== X-Google-Smtp-Source: APiQypIWYfgA0FdplveqGsur+9AHcll4xJXYa3vWGNz+ug9ix7/JbMfAsPP4Gt998cHkDj7ajgA7xhMcH1MlYZVB5wA= X-Received: by 2002:a92:24f:: with SMTP id 76mr21544181ilc.178.1586179196827; Mon, 06 Apr 2020 06:19:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Mon, 6 Apr 2020 22:19:45 +0900 Message-ID: To: Ron Bonica , Timothy Winters Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009413c605a29f1f07" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 13:27:46 -0000 --0000000000009413c605a29f1f07 Content-Type: text/plain; charset="UTF-8" Based on a fair amount of experience with this sort of thing, this recommendation is risky: * The lifetime values advertised for prefixes corresponding to a prefix leased via DHCPv6-PD should be dynamically updated (rather than static values), since otherwise the advertised lifetimes would eventually span past the DHCPv6-PD lease time. The reason is that there are many routers in the field that send RAs much too often. There are many devices that send RAs at the maximum permitted rate of one every three seconds (ironically, I think the reason for this is to prevent the very "client loses connectivity" roblem this draft is trying to solve). On a phone or smaller device, processing packets every 3 seconds will destroy battery life. But because phone manufacturers could not fix routers in the field, they reacted to this in different ways. 1. Drop all packets / all multicast packets / all RA packets when the "device is not in use" (e.g., screen is off). Maybe send an RS when the screen turns on again. 2. Drop RAs that are received too soon after an identical RA. 3. Drop RAs that are received too soon after a similar RA (e.g., same RA but with different lifetime values). #1 basically breaks IPv6 almost completely, because RAs will time out and expire. Even if the device sends an RS again when the screen turns on, connectivity might have been broken while the screen was off, because the device might have dropped one or more RAs with a critical update. Devices do need connectivity while the screen is off - for example, to receive incoming calls and chat messages. #3 works but not all manufacturers implement it. Android does this by providing the source code of a bytecode interpreter to chipset vendors and downloading bytecode to the interpreter based on previously-received RAs, but some chipset vendors don't support this. I don't think iOS supports this either. Many devices do #2. It sort of works as long as the RAs are identical. This is pretty common because it's easy to do in wifi firmware and pretty much all wifi chipsets support fixed-function filtering. By recommending that lifetimes should be dynamically updated, this draft will defeat devices that do #2. Based on past experience, a likely outcome is that manufacturers will react by switching to #1 and dropping all RAs. We should try to avoid making this problem worse with this draft. The safest way to do so would be to remove this text. A bit less safe would be to say that the device must cease to send RAs if the RA lifetime is below the DHCPv6 PD lifetime. A bit less safe would be to say here that the device MUST respect RFC 7772 and only send RAs once every few minutes. (The reason that this isn't super safe is that in a simple router that just glues together dhcpcd and dnsmasq/radvd, it's not easy to implement. The DHCPv6 client and the RA daemon are two separate pieces of software written by different authors, so transferring the DHCPv6 lifetime to the RA lifetime requires getting the two to collaborate.) +Timothy Winters any other suggestions? On Tue, Mar 31, 2020 at 12:47 AM Ron Bonica wrote: > Folks, > > > > This message initiates a WG Last Call on draft-ietf-v6ops-cpe-slaac-renum. > > > > Please submit comments by April 13, 2020. > > > > Fred and Ron > > Juniper Business Use Only > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000009413c605a29f1f07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Based on a fair amount of experience with this sort o= f thing, this recommendation is risky:

=C2=A0 = =C2=A0 =C2=A0 * =C2=A0The lifetime values advertised for prefixes correspon= ding to a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prefix leased via DHCPv6-PD = should be dynamically updated
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(rather = than static values), since otherwise the advertised
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0lifetimes would eventually span past the DHCPv6-PD lease time= .

The reason is that there are many routers in= the field that send RAs much too often. There are many devices that send R= As at the maximum permitted rate of one every three seconds (ironically, I = think the reason for this is to prevent the=C2=A0very "client loses co= nnectivity" roblem this draft is trying to solve). On a phone or small= er device, processing packets every 3 seconds will destroy=C2=A0battery lif= e. But because phone manufacturers could not fix routers in the field, they= reacted to this in different ways.
  1. Drop all packets / al= l multicast packets / all RA packets when the "device is not in use&qu= ot; (e.g., screen is off). Maybe send an RS when the screen turns on again.=
  2. Drop RAs that are received too soon after an identical RA.
  3. Drop RAs that are received too soon after a similar RA (e.g., same RA = but with different lifetime values).
#1 basically breaks IPv6= almost completely, because RAs will time out and expire. Even if the devic= e sends an RS again when the screen turns on, connectivity might have been = broken while the screen was off, because the device might have dropped one = or more RAs with a critical update. Devices do need connectivity while the = screen is off - for example, to receive incoming calls and chat messages. #= 3 works but not all manufacturers implement it. Android does this by provid= ing the source code of a bytecode interpreter to chipset vendors and downlo= ading bytecode to the interpreter=C2=A0based on previously-received RAs, bu= t some chipset vendors don't support this. I don't think iOS suppor= ts this either. Many devices do #2. It sort of works as long as the RAs are= identical. This is pretty common because it's easy to do in wifi firmw= are and pretty much all wifi chipsets support fixed-function filtering.

By recommending that lifetimes should be dynami= cally updated, this draft will defeat devices that do #2. Based on past exp= erience, a likely outcome is that manufacturers will react by switching to = #1 and dropping all RAs. We should try to avoid making this problem worse w= ith this draft.

The safest way to do so would be t= o remove this text. A bit less safe would be to say that the device must ce= ase to send RAs if the RA lifetime is below the DHCPv6 PD lifetime. A bit l= ess safe would be to say here that the device MUST respect RFC 7772 and onl= y send RAs once every few minutes. (The reason that this isn't super sa= fe is that in a simple router that just glues together dhcpcd and dnsmasq/r= advd, it's not easy to implement.=C2=A0The DHCPv6 client and the RA dae= mon are two separate pieces of software written by different authors, so tr= ansferring the DHCPv6 lifetime to the RA lifetime requires getting the two = to collaborate.)=C2=A0+Timothy Winters=C2= =A0any other suggestions?

On Tue, Mar 31, 2020 at 12:47 AM Ron Bonica = <rbonica=3D40juniper.net= @dmarc.ietf.org> wrote:

Folks,

=C2=A0

This message initiates a WG Last Call on draft-ietf-= v6ops-cpe-slaac-renum.

=C2=A0

Please submit comments by April 13, 2020.<= /u>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Fr= ed and Ron


Juniper Business Use Only

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--0000000000009413c605a29f1f07-- From nobody Mon Apr 6 06:32:25 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A303A12B3 for ; Mon, 6 Apr 2020 06:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 PUQjD8KfyKWs for ; Mon, 6 Apr 2020 06:32:06 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EA43A159A for ; Mon, 6 Apr 2020 06:27:54 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id g15so14583331ilj.10 for ; Mon, 06 Apr 2020 06:27:54 -0700 (PDT) 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=zQdJGF+ZZz/Et4WT3TBhTFCvxEhCGCHKqAmhiAO2yeM=; b=fiqHBu1e61ooCDNPFT25SsBYGWuq7qQSblzhOJpJSpS2o1R13bQRKjJCiMy29o47jf MsJEv077HgV9iLgirJEZ+JBh/+uc1Wm0X0f0IhxLajCxoZdaWFwwJ3tk1Q+Bsr/RhlyA SmmsMX575iYU4Rtv4gwcTzIlXmfSehOEaK8K0Gnlh/3Tuon2b61vIOZpxWFH1/IZY+GS AUFg8gptjd8EEP/gFunPxY2EGRtoPd+hkEJbkbN4OaT9Af8PZD9TMuNd91WG/V/+74fh SIY/Z+NpWytU49CLuTjBh/zKNmVWNfdb2KI+a/h1LT9FGaFTXUPxrxIeeGlcN0w89MAt E4UQ== 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=zQdJGF+ZZz/Et4WT3TBhTFCvxEhCGCHKqAmhiAO2yeM=; b=C8xlfzz7uBzbmmgld94xsaghfQIfsXoBR6swBkvE7LNy0ccrqJPmzlFv8nsiwwcVTQ JumCxVSr7mkqs842kO2e9zIyDqEL/uCQz9EPVEI74FW07I+ABrIL3mHbaLCmAaunkVD5 qoxKgENWcO7m8vPeCguB5cMZmwE4BRaIC8AR0v47ueJC4hV1YyIE4aIfvQNvpcrkw9Kd ur/IRdxT1BkozgTMnSa4S5ZzFV23NF30hsFVTJKaDNeE57CQFD8UVpIG4V3F+n/e/+ou rLPU78ZFV6llPY6BK4K9nF2IJpngcvqzlrHiBg2LlsG/lsY5XuTpsSUjAchenlXLryuR JGyg== X-Gm-Message-State: AGi0PuZcL+2DegMDpD6VODdvgnxR0SLC+y2n+pgv/RZ2VKefIEaifyA5 tCiRMVbvp9Pj8DYzrqDc4ps31Ey6+Mwe5L8ogk28Rw== X-Google-Smtp-Source: APiQypI3aZbFd4//zmuMHiIXfkZclV5xNU5rUVHXGBPlS4ikhOr2V/TtAFDV34CAHKo/mrNbpRqRXE+6wMwZyj3AXMA= X-Received: by 2002:a92:24f:: with SMTP id 76mr21582738ilc.178.1586179673310; Mon, 06 Apr 2020 06:27:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Mon, 6 Apr 2020 22:27:42 +0900 Message-ID: To: Ron Bonica Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000faba5305a29f3bd9" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 13:32:17 -0000 --000000000000faba5305a29f3bd9 Content-Type: text/plain; charset="UTF-8" Has this text: o A CE router sending RAs that advertise dynamically-learned prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on stable storage, the list of prefixes being advertised on each network segment, and the "A" and "L" flags of the corresponding PIOs. been run past manufacturers of home gateways? Depending on how write many cycles the flash allows, and on how low the prefix lifetimes are, this might not be feasible on real products. On Tue, Mar 31, 2020 at 12:47 AM Ron Bonica wrote: > Folks, > > > > This message initiates a WG Last Call on draft-ietf-v6ops-cpe-slaac-renum. > > > > Please submit comments by April 13, 2020. > > > > Fred and Ron > > Juniper Business Use Only > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000faba5305a29f3bd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Has this text:

=C2=A0 =C2=A0o =C2=A0A C= E router sending RAs that advertise dynamically-learned
=C2=A0 =C2=A0 = =C2=A0 prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on
=C2= =A0 =C2=A0 =C2=A0 stable storage, the list of prefixes being advertised on = each
=C2=A0 =C2=A0 =C2=A0 network segment, and the "A&qu= ot; and "L" flags of the corresponding
=C2=A0 =C2=A0 =C2=A0 PI= Os.

been run past manufacturers of home gatewa= ys? Depending on how write many cycles the flash allows, and on how low the= prefix lifetimes are, this might not be feasible on real products.

On= Tue, Mar 31, 2020 at 12:47 AM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:

Folks,

=C2=A0

This message initiates a WG Last Call on draft-ietf-= v6ops-cpe-slaac-renum.

=C2=A0

Please submit comments by April 13, 2020.<= /u>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Fr= ed and Ron


Juniper Business Use Only

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000faba5305a29f3bd9-- From nobody Mon Apr 6 06:40:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7157E3A1090 for ; Mon, 6 Apr 2020 06:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.588 X-Spam-Level: X-Spam-Status: No, score=-9.588 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 gY4xsSLU-0Qo for ; Mon, 6 Apr 2020 06:40:39 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-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 8391E3A10CF for ; Mon, 6 Apr 2020 06:26:14 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id a6so14639194ilr.4 for ; Mon, 06 Apr 2020 06:26:14 -0700 (PDT) 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=GGSJQezXEERHxLkpD7mKtZIitqYt4yvwcyE/qYhgVfQ=; b=BVqCaWFHgz7UYQ2Y8KmzX2f7jVSN652NWJMBmZKk1EK/NdSdIM8bo0i/KH1MvZ0pGJ 5RUcYC99sbcMZIc2oAt1RjZJYl/p0JAADMQ2akZ8mssQeZ0l4ulHvurJZcxM5ugrpf15 /kA1R334O42clklDkascE+9cyZd8orrodr0Dnr5EuEs1Ang+UbZd7vimlzT4EaOq5WLO G6P0/h+Fe+tq4ZjESYGlD4DVPpE8+rxWb15EW2hnczIXZs2eOZhNJQU9F2UVb8UQRavL ijj5cf7C3dxLO5Ow7vj0kOR2F35oEzeXW8RjZavnidQbP+0Xu27eydH6QAwxcf/+/q3D pqvA== 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=GGSJQezXEERHxLkpD7mKtZIitqYt4yvwcyE/qYhgVfQ=; b=SCNCiRt9+DZEvrrBrFp2gHbU9AcQHOa7KJwRz/8uDk0yoWY461Bgce1fu7jBHlzLbZ XJejPDfkQo1h7ZMVxop8sv39bBTkdAb0/rUvvJG2tyywCgteipVwnhaq35+/Te3FmxPc DX9wZjJU7Or1v5biMEP7+2xqt62rfOzKxBjtTJwJgne4wH9jEJvvHHMQMlScnGDqQXed /rEqkf4RtC/7d0ocbVRMMwHwfe08WYzPbdgiddHHrqkB7a0FZ1UapFbbLsbk2/aeSLo/ T6jlnmvHtSfuu86B/nla1lwUf2qii5Rp1SSJR7xzvfBunqTtI4MP2LfhWDup3/jIXpJO k2tg== X-Gm-Message-State: AGi0PuYKItSpAwKsOa3/xQj+maIqyzID4p8YPI/LFKc97pf3lHhwMhoc 7VoBDr7yV0WUfW9NZFMH+tHrdl0h4zC4pIAxADR/80QsiScvDw== X-Google-Smtp-Source: APiQypKR2B5xcgRS4kXiEpSBSmw0Pk4fUAbH2bVo57lK0wvTe5Cc0T8qjWYZ18zH/3pvjFq3+6yZwfE2vagq6bPMYqg= X-Received: by 2002:a92:364f:: with SMTP id d15mr22221756ilf.0.1586179573409; Mon, 06 Apr 2020 06:26:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Mon, 6 Apr 2020 22:26:01 +0900 Message-ID: To: Ron Bonica Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000661d905a29f36c7" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 13:40:46 -0000 --0000000000000661d905a29f36c7 Content-Type: text/plain; charset="UTF-8" This text: o Upon changes to the advertised prefixes, and after bootstrapping, the CE router advertising prefix information via SLAAC should proceed as follows: * Any prefixes that were previously advertised via Router Advertisement (RA) messages, but that have now become stale, MUST be advertised with a "Valid Lifetime" and a "Preferred Lifetime" set to 0, and the "A" and "L" bits unchanged. * The aforementioned advertisement SHOULD be performed for at least the "Valid Lifetime" previously employed for such prefix. is risky because if the link is flapping, then there could be too many PIOs in the RA, causing the packet to become too big. If the implementer does not anticipate this problem, it will result in fragmentation (making it unlikely that the RA will be received by clients) or just not sending RAs entirely because the send operation fails with EMSGSIZE. The text also does not say what to do with other data that's related to the prefix, such as on-link DNS servers. Some routers will announce themselves as the DNS server for the subnet by picking something like ::1 and announcing it in RDNSS. That information is as stale as the prefixes themselves. On Tue, Mar 31, 2020 at 12:47 AM Ron Bonica wrote: > Folks, > > > > This message initiates a WG Last Call on draft-ietf-v6ops-cpe-slaac-renum. > > > > Please submit comments by April 13, 2020. > > > > Fred and Ron > > Juniper Business Use Only > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000000661d905a29f36c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This text:

=C2=A0 =C2=A0o =C2=A0Upon ch= anges to the advertised prefixes, and after bootstrapping,
=C2=A0 =C2=A0= =C2=A0 the CE router advertising prefix information via SLAAC should
= =C2=A0 =C2=A0 =C2=A0 proceed as follows:

=C2=A0 =C2=A0 =C2=A0 * =C2= =A0Any prefixes that were previously advertised via Router
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Advertisement (RA) messages, but that have now become = stale,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be advertised with a "= ;Valid Lifetime" and a "Preferred
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Lifetime" set to 0, and the "A" and "L" bits= unchanged.

=C2=A0 =C2=A0 =C2=A0 * =C2=A0The aforementioned advertis= ement SHOULD be performed for at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0least= the "Valid Lifetime" previously employed for such prefix.

is risky because if the link is flapping, then there= could be too many PIOs in the RA, causing the packet to become too big. If= the implementer does not anticipate this problem, it will result in fragme= ntation (making it unlikely that the RA will be received by clients) or jus= t not sending RAs entirely because the send operation fails with EMSGSIZE.<= /div>

The text also does not say what to do with other d= ata that's related to the prefix, such as on-link DNS servers. Some rou= ters will announce themselves as the DNS server for the subnet by picking s= omething like <prefix>::1 and announcing it in RDNSS. That informatio= n is as stale as the prefixes themselves.

On Tue, Mar 31, 2020 at 12:4= 7 AM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:

Folks,

=C2=A0

This message initiates a WG Last Call on draft-ietf-= v6ops-cpe-slaac-renum.

=C2=A0

Please submit comments by April 13, 2020.<= /u>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Fr= ed and Ron


Juniper Business Use Only

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--0000000000000661d905a29f36c7-- From nobody Mon Apr 6 06:47:45 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAC03A108D for ; Mon, 6 Apr 2020 06:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9gs0J0wrb6d for ; Mon, 6 Apr 2020 06:47:41 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D713A108A for ; Mon, 6 Apr 2020 06:47:41 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79d:53aa:d30:a802:1264:bb16:f7ba]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id A37714E11AFC; Mon, 6 Apr 2020 13:47:40 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 572E3314C671; Mon, 6 Apr 2020 15:47:35 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Mon, 6 Apr 2020 15:47:35 +0200 Cc: Ron Bonica , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 13:47:43 -0000 > Has this text: >=20 > o A CE router sending RAs that advertise dynamically-learned > prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on > stable storage, the list of prefixes being advertised on each > network segment, and the "A" and "L" flags of the corresponding > PIOs. >=20 > been run past manufacturers of home gateways? Depending on how write = many cycles the flash allows, and on how low the prefix lifetimes are, = this might not be feasible on real products. ah, yes this was the comment I forgot. This issue was brought up multiple times. The text has to be losened and = more explanatory. Cause this is a no-go for lots of devices without = persistent storage. Cheers, Ole From nobody Mon Apr 6 07:08:46 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99313A0484 for ; Mon, 6 Apr 2020 07:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou8Sr-IYkRNW for ; Mon, 6 Apr 2020 07:08:41 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BCE3A045B for ; Mon, 6 Apr 2020 07:08:40 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 062A0832B0; Mon, 6 Apr 2020 16:08:35 +0200 (CEST) To: Lorenzo Colitti , Ron Bonica , Timothy Winters Cc: "v6ops@ietf.org" , Mark Smith References: From: Fernando Gont Message-ID: Date: Mon, 6 Apr 2020 11:06:12 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 14:08:44 -0000 Lorenzo, On 6/4/20 10:19, Lorenzo Colitti wrote: > Based on a fair amount of experience with this sort of thing, this > recommendation is risky: > >       *  The lifetime values advertised for prefixes corresponding to a >          prefix leased via DHCPv6-PD should be dynamically updated >          (rather than static values), since otherwise the advertised >          lifetimes would eventually span past the DHCPv6-PD lease time.. As noted in the draft, these requirements are already part of RFC4862 and RFC8415. THey are *existing* requirements which are referenced here, because they are of use to solve the problem at hand. That said, I don't mind adding a reference to RFC7772. > The safest way to do so would be to remove this text. A bit less safe > would be to say that the device must cease to send RAs if the RA > lifetime is below the DHCPv6 PD lifetime. A bit less safe would be to > say here that the device MUST respect RFC 7772 and only send RAs once > every few minutes. (The reason that this isn't super safe is that in a > simple router that just glues together dhcpcd and dnsmasq/radvd, it's > not easy to implement. The DHCPv6 client and the RA daemon are two > separate pieces of software written by different authors, so > transferring the DHCPv6 lifetime to the RA lifetime requires getting the > two to collaborate.) +Timothy Winters  any > other suggestions? FWIW, radvd already supports this, which support implemented by Mark Smith years ago. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 6 07:14:11 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC7E3A0745 for ; Mon, 6 Apr 2020 07:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Jpjtl989; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=goGnNclF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roZUvIyO_INe for ; Mon, 6 Apr 2020 07:13:57 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84B43A0835 for ; Mon, 6 Apr 2020 07:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2040; q=dns/txt; s=iport; t=1586182431; x=1587392031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=U0SO97WTZJJT0sCkIrMwA0vrytStzSxx328fig9QdAo=; b=Jpjtl989+hq7+JxGJg06ZcXNdUQ8wXgNuYCOTLIUWdp4ZXnxFGnSyGps pMOGJkK6ASxDLw3EqUOqvc0+nn+r/f0dAl1UsJoZjy3nqh1FZi5D2xAsq w8dyDyNtOq8di7GuVve2iKpxcTa/ayrLx6INwu1EzjMH/iEx52c7sQtTm w=; IronPort-PHdr: =?us-ascii?q?9a23=3AsyshhBOsw95uzQTUvpUl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKg/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQF0r/PtbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAACoOIte/5FdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gVRQBWxYIAQLKgqHVgOKZYJfmB6CUgNUCgE?= =?us-ascii?q?BAQwBARgLCgIEAQGERAKCSSQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFcAEBAQE?= =?us-ascii?q?CAQEBECgGAQEsCwEEBwQCAQgRBAEBHxAnCx0IAQEEAQ0FCBqDBYJLAw4gAQ6?= =?us-ascii?q?lFAKBOYhigieCfwEBBYEvAYQPGIINAwaBOIwzGoIAgVSCTT6CZwEBAoFlg0K?= =?us-ascii?q?CLI4Ai26XNAqCPZdHgk6IOJB8i0CDd4FSmlMCBAIEBQIOAQEFgWkigVdwFTu?= =?us-ascii?q?CaVAYDY4dg3OFFIVBdAKBJ40fATBfAQE?= X-IronPort-AV: E=Sophos;i="5.72,351,1580774400"; d="scan'208";a="472041872" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Apr 2020 14:13:50 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 036EDoiL028703 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Apr 2020 14:13:50 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 09:13:50 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 09:13:49 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 6 Apr 2020 10:13:49 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CCLWCe1QlasSySPJgXA3ubopBUQg7tzcsfoUmUMh23neoQwoW0/ZTq5bWBpPHxbbAmXFenW/ihE5EmJCCq731xbsybOiNt5AH5+PGVf5D+uPA7SLXBTKX2s8UnFkQc6+do/Bk1IQ4zUAKnNea0cigmSEk/8BxSYfGhTkF9yMyiJecqHbBPeh/oOdRf0uO6vOtUoK3g18uLZ8T62BBB+knf3RIztq7PLLEBq4EZWU7GsrFcoQZc+6QIqQf/pLCsRtuyIgrAVtcPx6lpn+yNkSoD8cqOkwJSOiuExxEnB26CUSkXd7TWxatEckMt+7U7JoV2lXBCKYo6UoTPa24NnH0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U0SO97WTZJJT0sCkIrMwA0vrytStzSxx328fig9QdAo=; b=Vn2JmXwIkGUgyXIHeQRH7+mXl8SxVszJ2iXLXIPU15Eem2+mAhDcIlEixuz/S+9Fp2udOZLPShTKUZXcf3lM8EkCizk4zDCAcsX3x0hgSabdCH6KUMl9rlonn45P1j8e9RZanWpz6YldGGOt+E8jaKTY9bYdBmieZHmA/kBN80EQutPFN8HWT0BhY4QtzYGngOnAmrE+j/X2Gu3beEr1vgUXQrM/+UbLiejey+HAhlwU9uc9AdwtF1k0NcCOvBxUHdUEihntq8XRtoKPBB0GAX186Y4EewIalWf/9uXAaMx6LcdS4F8mPk3zBENXVHhqUdylkUMzlV7bTAd0vQhFsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U0SO97WTZJJT0sCkIrMwA0vrytStzSxx328fig9QdAo=; b=goGnNclFdOQAaGbwvLYK0hYbeakGyZWrDkwN/8KWCwD1RTOpv7D6edom9tChaYrluDiJMcAym1J8Rg1xXK2kiMGBrHgiyYvwXqb3W/72tV2D27Cn5P6NY5STfYyspq1e4aJF2vBnuxHW23/6ChMBRwJ8tLIBJPjZospGAIecZ9Q= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2609.namprd11.prod.outlook.com (2603:10b6:406:b1::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Mon, 6 Apr 2020 14:13:48 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 14:13:48 +0000 From: "Bernie Volz (volz)" To: "otroan@employees.org" , Ron Bonica CC: "v6ops@ietf.org" Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdYGqnrRGOoD4f0yRz2uh9FnYboxrQFaGSGAAAIsGEA= Date: Mon, 6 Apr 2020 14:13:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 370f8141-c6a2-47f1-d46c-08d7da34b990 x-ms-traffictypediagnostic: BN7PR11MB2609: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(346002)(366004)(136003)(186003)(81166006)(8676002)(71200400001)(52536014)(8936002)(66556008)(64756008)(2906002)(66476007)(4326008)(66446008)(33656002)(66946007)(76116006)(7696005)(81156014)(478600001)(966005)(55016002)(316002)(110136005)(86362001)(5660300002)(6506007)(9686003)(26005)(53546011); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c5Gb3AEXSvDg3G2T7aZ3gP9LUKZzi+EXVf1GgjQc9fu7pDRAlf5ChRHOQ5Vqg5+OPWh6fJwsXzyAK6nYLMIOHD6TetvLqOMbZo1YZQiIpf2Syb3j6awBkVhlJ/KILqx9eoCI5T52mA8y3bLBttmm7bdxeuedu2ZgI4+BXydBGapZv0eLqFSVoWzb9bVToT0C4OtXmb5gfX/kbFCB5pWonOsh6ugQvq4ahc9dAHBhz4U+pniGj/y7NBUREazNlAVszEHGj5r5dr+UBxGXbUkfM27hJN3u8ezw2jLnDvkQV9grETtgHrrTmvkKqNI+wZOfSFtY2wlCNw1srwsK9BG6of35ePRM+vtbccGWgCl/xvjjdFitJIZG8cTtdXa6F/1m57mGoVisHyI79EULjPHn4a1bDcAoTGEZmJzV9DwTlHLBYkG7RqqJ1aDcMT+2gVnxjo0ik+EapbWxq08/JUURP60LPWiAG5yMYqgPRnA11rode6yyRWmcdHKkkkT+IxP/AmJPLr2Du6JKnLnKBaVnSg== x-ms-exchange-antispam-messagedata: 2EYak7vro9yXfkibna5x8aENLsAXlsVQM28AbtDCxfYu8wMJZpo0c5ikVKnLjnk37PVf+R7UjpBpVziovzPDdRvTHuLbkmZAGbEqriVM5XxOYa6DqGZmwfWfoCCc2j0yRj+ZJ88q48LA1xw4y/Hmsw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 370f8141-c6a2-47f1-d46c-08d7da34b990 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 14:13:48.0886 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /zm3HAfVbrVr0FnJmWGHQtBJ90AaTxfv+CIDYgY7sWqQNs8iRTKBm6vcT2BaJxAO X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2609 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 14:14:09 -0000 Hi: >Something like: "A network provider that has to renumber a customer networ= k, must continue to include the old prefix in DHCP PD messages with lifetim= es set to 0 for a while, to ensure that stale prefix information can be exp= ired on hosts attached to the network That would be a change to DHCPv6 as there is no such clear requirement in t= hat specification. The "for a while" would be until the (longest communicat= ed) valid lifetime would have expired. What is being proposed is that the CPE remember this information. - Bernie -----Original Message----- From: v6ops On Behalf Of otroan@employees.org Sent: Monday, April 6, 2020 8:57 AM To: Ron Bonica Cc: v6ops@ietf.org Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum > This message initiates a WG Last Call on draft-ietf-v6ops-cpe-slaac-renum= . > =20 > Please submit comments by April 13, 2020. 0) Remove the reference to the individual draft in introduction. 1) the document proposes a workaround for the case where the service provid= er does not renumber the network correctly. It would be useful to add a paragraph in the introduction describing the "c= orrect" procedure. This to ensure that a reader would not be confused and t= hink this is how the DHCP PD mechanism is intended to work. I don't think there is a reference for that, I'm not sure we have written d= own the correct DHCP PD behaviour when doing instant renumbering? Something like: "A network provider that has to renumber a customer network= , must continue to include the old prefix in DHCP PD messages with lifetime= s set to 0 for a while, to ensure that stale prefix information can be expi= red on hosts attached to the network". 2) Rewrite the document as an update to RFC7084. Make the new requirements = as WPD- Ole _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Apr 6 07:18:47 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198AF3A060A for ; Mon, 6 Apr 2020 07:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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 4QUxOEpMTIwT for ; Mon, 6 Apr 2020 07:18:35 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C043A0747 for ; Mon, 6 Apr 2020 07:18:35 -0700 (PDT) Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 3B7DB4E11B6D; Mon, 6 Apr 2020 14:18:34 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id D2862314D3AE; Mon, 6 Apr 2020 16:18:28 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Mon, 6 Apr 2020 16:18:28 +0200 Cc: Ron Bonica , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <52688D39-5537-44BA-B1C8-4341C21D1B02@employees.org> References: To: Bernie Volz X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 14:18:44 -0000 Bernie, >> Something like: "A network provider that has to renumber a customer = network, must continue to include the old prefix in DHCP PD messages = with lifetimes set to 0 for a while, to ensure that stale prefix = information can be expired on hosts attached to the network >=20 > That would be a change to DHCPv6 as there is no such clear requirement = in that specification. The "for a while" would be until the (longest = communicated) valid lifetime would have expired. >=20 > What is being proposed is that the CPE remember this information. Why do you think it's a change to "DHCPv6"? This is how DHCP PD has always worked. The only difference between flash renumbering and normal renumbering is = that there is no overlap in time between old and new prefix. The CPE cannot in many cases remember the information. And it is the = responsibility of the delegating entity to manage that information. What is proposed in this draft is a workaround for an error case, that = shouldn't have happened in the first place. I don't mind us providing a band aid for it, but as I suggested let's = make it clear what intended behaviour is. Cheers, Ole= From nobody Mon Apr 6 07:21:59 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8123A0794 for ; Mon, 6 Apr 2020 07:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 GlGHn2tJcqAr for ; Mon, 6 Apr 2020 07:21:56 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8343A0B5B for ; Mon, 6 Apr 2020 07:21:03 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 2D4D2808C3; Mon, 6 Apr 2020 16:20:59 +0200 (CEST) To: Lorenzo Colitti , Ron Bonica Cc: "v6ops@ietf.org" References: From: Fernando Gont Message-ID: Date: Mon, 6 Apr 2020 11:20:08 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 14:21:58 -0000 On 6/4/20 10:26, Lorenzo Colitti wrote: > This text: > >    o  Upon changes to the advertised prefixes, and after bootstrapping, >       the CE router advertising prefix information via SLAAC should >       proceed as follows: > >       *  Any prefixes that were previously advertised via Router >          Advertisement (RA) messages, but that have now become stale, >          MUST be advertised with a "Valid Lifetime" and a "Preferred >          Lifetime" set to 0, and the "A" and "L" bits unchanged. > >       *  The aforementioned advertisement SHOULD be performed for at >          least the "Valid Lifetime" previously employed for such prefix. > > is risky because if the link is flapping, then there could be too many > PIOs in the RA, causing the packet to become too big. If the implementer > does not anticipate this problem, it will result in fragmentation > (making it unlikely that the RA will be received by clients) or just not > sending RAs entirely because the send operation fails with EMSGSIZE. Fair enough. There are multiple possible ways forward here: 1) The CPE only announces the previous set of network configuration information. i.e., upon reboot, the CE Router will announce the new information, plus the possible stale one. If you reboot it again, same: it announce whatever has become the new set of information, and the previous one. 2) Note that advertising stale information should be limitted to the link's MTU. "1)" seems more appropriate to me. And at the end of the day you alway need to enfoce a limit on how much you store, and how much you advertise. > The text also does not say what to do with other data that's related to > the prefix, such as on-link DNS servers. Some routers will announce > themselves as the DNS server for the subnet by picking something like > ::1 and announcing it in RDNSS. That information is as stale as > the prefixes themselves. Presumably, that information is still usable. However, fair enough. We could also add a note about this (including RIOs), which my local CE Router sends to hosts. 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 Mon Apr 6 07:22:39 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EEC3A0747 for ; Mon, 6 Apr 2020 07:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ijd1UhMeHui for ; Mon, 6 Apr 2020 07:22:30 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0CC3A0958 for ; Mon, 6 Apr 2020 07:22:11 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 8AFE7808C3; Mon, 6 Apr 2020 16:22:08 +0200 (CEST) To: otroan@employees.org, Lorenzo Colitti Cc: Ron Bonica , "v6ops@ietf.org" References: From: Fernando Gont Message-ID: <189f50a8-6b84-d533-6025-83b1cad9755e@si6networks.com> Date: Mon, 6 Apr 2020 11:22:03 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 14:22:37 -0000 On 6/4/20 10:47, otroan@employees.org wrote: >> Has this text: >> >> o A CE router sending RAs that advertise dynamically-learned >> prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on >> stable storage, the list of prefixes being advertised on each >> network segment, and the "A" and "L" flags of the corresponding >> PIOs. >> >> been run past manufacturers of home gateways? Depending on how write many cycles the flash allows, and on how low the prefix lifetimes are, this might not be feasible on real products. > > ah, yes this was the comment I forgot. > This issue was brought up multiple times. The text has to be losened and more explanatory. Cause this is a no-go for lots of devices without persistent storage. I do agree this should be losened to a SHOULD, since, as you note, there are valid reasons for which an implementation might not be able to do it. Could you expand on what you mean by "explanatory"? 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 Mon Apr 6 07:26:00 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA863A07E9 for ; Mon, 6 Apr 2020 07:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=W+vLn/Dz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=v+0scxBk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sLPXUNmfRTx for ; Mon, 6 Apr 2020 07:25:51 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDA43A07FB for ; Mon, 6 Apr 2020 07:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2425; q=dns/txt; s=iport; t=1586183129; x=1587392729; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Fdt9fBLzNb5H1358GbG8AYqgCnEcDrTOTs6zE1tXaAk=; b=W+vLn/DzUWO6a73wIWbG9lcYBqlEThJOl5tN3X2O7OPUvWj3WHn3qGbx haadXv0+1OmfBGHsN8HHyVD/WB7oJsIKLqylpkLlZUx7Mx8sX/nfAiHpF mltwNPeqdWI9/S7EEk54vjEA3XVuAfbDEjQPiC1iMmEwugnIpzs3oKIEt k=; IronPort-PHdr: =?us-ascii?q?9a23=3Au0e9aBYsa2lULn+7jI1gYyn/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20QKbRp3VvvRDjeee87vtX2AN+96giDgDa9QNHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuMvnufQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcBQCjOote/40NJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVFAFgUQgBAsqCodWA4pmgl+YHoJSA1QKAQEBDAEBLQIEAQG?= =?us-ascii?q?ERAKCSSQ4EwIDAQELAQEFAQEBAgEFBG2FVgELhXABAQEBAgESKAYBATcBCwQ?= =?us-ascii?q?CAQgRBAEBHxAyHQgBAQQOBQgahVADDiABpSsCgTmIYoIngn8BAQWFPBiCDQm?= =?us-ascii?q?BOIwzGoIAgRFDgk0+gmcEgUsCGINCgiyOAItuljp6CoI9jU2JeoJOjRWMH4t?= =?us-ascii?q?Ag3ecJQIEAgQFAg4BAQWBaSKBV3AVO4JpUBgNjh0MF4NQilV0AoEni22BMgE?= =?us-ascii?q?wXwEB?= X-IronPort-AV: E=Sophos;i="5.72,351,1580774400"; d="scan'208";a="746817782" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Apr 2020 14:25:27 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 036EPRBO031740 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Apr 2020 14:25:27 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 09:25:27 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 09:25:27 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 6 Apr 2020 09:25:26 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BWDt3N/47nCLxtCNZEX97+gLTgvf/A9GMTSwSPCtm54MKiJE5yqaa7XjubxOi7oAc7ARhi71cVB9xzVQU97a+yLMASeQ3RvAcz9wi94Ekn2/NTwjgP+YlmiUkJpGaEyxbRuXQCdK/8Xnc0A9ZV4IvTemYW7YWIzrd7L8lMmwZSoB5ZLg9/J89FT2ESikhxJyBb3O1YvMdJTtKh71RIbTi3IkMsmRZAzmQbPx3/zmVoGHvSMddtRRd1zChE/RDILLDq1M3vSWtZSOSHvBSeLZnXf2V2op1PembqTiDbSEypXfEuOiDGzrqrqPbyUVGOihw3Rsq5n1H4cgWMgHWdgr0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mNvyhCrBDVnQzEcWhWB4tYp7Cf5OtkaEtmzuWEc/bvg=; b=M4DhgpSDXjL9nPeRg8IqVCS8WyLnY/VplC4raqJ843SsTRJgtqixtTIH8rLin6mNuOLAlYM0M1spzZL17oTO8UTRt9h2a/piVqyxRuxfOV70cWFaR7WyWuRHpHiKOR8jUX+WmB1CseNv/vA7KkJN+0rmSbXOoeB4KtJUqwtuoSNTRL53+PmylQ7rsbTxJ3tCqSoSMLclYxHuUK5Xx7nrZ4pWFTgubJTPwJX+p4fTqcQGoZg0PeiBf4ZCLDMG3eh1JQVFDcnfyGXLhz/o8ESGk/D5EXRnpU4S7GS/m1hOeRW9vTGRmuHNnHCLGGWKZ9DGFdxMN1xdHMlRBxQYdiDBgA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mNvyhCrBDVnQzEcWhWB4tYp7Cf5OtkaEtmzuWEc/bvg=; b=v+0scxBkpGzBATvFyhW7Gh7kwjpbe2Zzt3iTMRWSuamc5zMuJAoiWQel83v+4Nh0AOht+1Smps9MpmKgdE2lmf9awq4oFN9+fFgWDPFGnDiYuk6l8+bwYhogj5+a9CoUdu2PkjVCQvHyVeUN64YgLM62kVbMhxzkTroMMiOKqmk= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2531.namprd11.prod.outlook.com (2603:10b6:406:ba::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 14:25:25 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 14:25:25 +0000 From: "Bernie Volz (volz)" To: "otroan@employees.org" CC: Ron Bonica , "v6ops@ietf.org" Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdYGqnrRGOoD4f0yRz2uh9FnYboxrQFaGSGAAAIsGEAAAKuIAAAAIs2g Date: Mon, 6 Apr 2020 14:25:24 +0000 Message-ID: References: <52688D39-5537-44BA-B1C8-4341C21D1B02@employees.org> In-Reply-To: <52688D39-5537-44BA-B1C8-4341C21D1B02@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8a887b1a-37ab-4b5d-332e-08d7da3658f2 x-ms-traffictypediagnostic: BN7PR11MB2531: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(366004)(376002)(136003)(39860400002)(396003)(33656002)(86362001)(2906002)(53546011)(8676002)(66574012)(81166006)(478600001)(81156014)(6916009)(8936002)(4326008)(71200400001)(316002)(55016002)(6506007)(54906003)(76116006)(186003)(52536014)(9686003)(66946007)(64756008)(66446008)(66476007)(5660300002)(7696005)(66556008)(26005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bz2z1yubqO1/c8sH129rDasqUBgj6SToRwKNICcPCA8yi0uCxfw26+pAN9wy7ZYTKU4hh6AIX5FtCpyijOEnhwJbSt6x5YByJEEvpxsVZujESyJeGDEpVejxHx8roTGneaP6h843x8OppeQMpxc61fmU9dFQjwnVlRyT4mWMCS2DXWciG+zerUXFDUNNf63V9zIuRJCgW709xMt8Fb3FL7euX7Q+q6QlnHu/e6P61HRwfoVW/kvDjuAz35/ujAQmMaE97MjemCAQ6GqE9XqtW7JGabzobYGxZq67LBuJbfLuzx/82p8aRPK3kutiHNYGyc3FWm0IljXmQnxkImvgXr1lhrmsh5FuqsfXytM0QefoRKOXa3y7lwyHDNc1XMaAfaG9lHEjODtXtGNUstW2qt/DX/pEl74G92yNBytGx5TyeXsOiRApJC8njFdq6pa7 x-ms-exchange-antispam-messagedata: iki5ELjfXJ1+2DR626z3znGXtyXx35hJqAAfBz7wUhxYJmbC3fLCPRwS4Y8T9YgMsF4i5T7d8QOT5Jcl1CaIjYfuKyEvQulvVjYp370uEJEgP4SJeHp61G+ohpSHLK/dDVgbqMUUccd//JJASHUmLg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8a887b1a-37ab-4b5d-332e-08d7da3658f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 14:25:25.0272 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WgXLAS7RykYA+DeV0YA0x2DvXBogQvJefBbawdF5wQjjvKQFxtn2bDAtIL9q8iKy X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2531 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 14:25:57 -0000 The question is how long this information has to be remembered and sent to = the client. I don't think RFC8415 is that clear on this issue. Yes, when the old PD is switched to a new PD, the server would be expected = to send the old PD with 0 lifetimes. But how long will the server remember = this is the key question and, for example if 30 days were remaining on the = old PD, it should keep sending it for 30 days. If you read the text of the proposed draft, it only puts a requirement on t= he CPE: 2.2. Signaling Stale Configuration Information In order to phase-out stale configuration information: o A CE router sending RAs that advertise dynamically-learned prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on stable storage, the list of prefixes being advertised on each network segment, and the "A" and "L" flags of the corresponding PIOs. - Bernie -----Original Message----- From: otroan@employees.org =20 Sent: Monday, April 6, 2020 10:18 AM To: Bernie Volz (volz) Cc: Ron Bonica ; v6ops@ietf.org Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Bernie, >> Something like: "A network provider that has to renumber a customer netw= ork, must continue to include the old prefix in DHCP PD messages with lifet= imes set to 0 for a while, to ensure that stale prefix information can be e= xpired on hosts attached to the network >=20 > That would be a change to DHCPv6 as there is no such clear requirement in= that specification. The "for a while" would be until the (longest communic= ated) valid lifetime would have expired. >=20 > What is being proposed is that the CPE remember this information. Why do you think it's a change to "DHCPv6"? This is how DHCP PD has always worked. The only difference between flash renumbering and normal renumbering is tha= t there is no overlap in time between old and new prefix. The CPE cannot in many cases remember the information. And it is the respon= sibility of the delegating entity to manage that information. What is proposed in this draft is a workaround for an error case, that shou= ldn't have happened in the first place. I don't mind us providing a band aid for it, but as I suggested let's make = it clear what intended behaviour is. Cheers, Ole From nobody Mon Apr 6 07:49:38 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CBD3A095F for ; Mon, 6 Apr 2020 07:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qacafe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SvOZKQZdcIs for ; Mon, 6 Apr 2020 07:49:16 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB94F3A0944 for ; Mon, 6 Apr 2020 07:49:15 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id p10so17814396wrt.6 for ; Mon, 06 Apr 2020 07:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QCrZyKkK6OVoK87pmQuI/WdKlck/pjxhv/qnj8ZFuMs=; b=hLToMgVzrT8BNI7LFJQiUbjZNR/1PKSs1O7UacXE2op93amBl7LTXLEE493/hACwSc L4Pwdi8FjzJs+6Bk60KSBEgqbzCqaACF+YS/sqUmD5HfMn8Mp6mFNDDO0EBrHI03XdR4 xtRV8kWLMDw+l/9xBGUJG5N5R/lZaGsnHZHcM= 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=QCrZyKkK6OVoK87pmQuI/WdKlck/pjxhv/qnj8ZFuMs=; b=C8qLXBVgXEvTC/Vl35oEZePUOzmRfDlMW3lwP0W/ovSTQcmrLk8y10O+Qkk6xkgcwu Wa1rbdC8ecukMGtAnw9Ui7jrDBlc2t0PmjwlfEV1dhPJkt6Jbf0SnlSxFUiLEL3nbp8J +ypwYUCss6Ns4KNMPV7C5gP61FXMlXsfz2JW1huFq9qi0AfMfJ+zTRIO9cIGxxpw1RoK x/tnuasYo6dkGvoZ9Xv5FdPKXT9T2GDkaK72Mbg62BV23wQVypKeK0J+ohkcjdiuCgIn 74y7Eh4oK/zHYQzvtCg1YqVJv2v7DPL8kXYQMyPpfRfZPHgV/o7HGLPAx8fWNuWVe2US RXQA== X-Gm-Message-State: AGi0PubeYRlrwygu63JfENW5Z8b7wYAoT3hHr4JD5F1NJF6GZpLpdOx2 Amj159jvHoS3rJOnOBGgtLqw/1w5xBsPJo3N4z/F3P9s4hA= X-Google-Smtp-Source: APiQypJSaa4fNOchRbK0P0H9B24yE/qZnS79bkAjPubfF1dE8gsOudBtzch1PtsExp6yDCva96q9PA4xwvBTGESBlVM= X-Received: by 2002:a5d:5688:: with SMTP id f8mr7408264wrv.245.1586184554362; Mon, 06 Apr 2020 07:49:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Timothy Winters Date: Mon, 6 Apr 2020 10:49:03 -0400 Message-ID: To: Fernando Gont Cc: Lorenzo Colitti , Ron Bonica , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e94a6b05a2a05ec0" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 14:49:20 -0000 --000000000000e94a6b05a2a05ec0 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 6, 2020 at 10:09 AM Fernando Gont wrote: > Lorenzo, > > On 6/4/20 10:19, Lorenzo Colitti wrote: > > Based on a fair amount of experience with this sort of thing, this > > recommendation is risky: > > > > * The lifetime values advertised for prefixes corresponding to a > > prefix leased via DHCPv6-PD should be dynamically updated > > (rather than static values), since otherwise the advertised > > lifetimes would eventually span past the DHCPv6-PD lease time.. > > As noted in the draft, these requirements are already part of RFC4862 > and RFC8415. THey are *existing* requirements which are referenced here, > because they are of use to solve the problem at hand. > > That said, I don't mind adding a reference to RFC7772. > > > > The safest way to do so would be to remove this text. A bit less safe > > would be to say that the device must cease to send RAs if the RA > > lifetime is below the DHCPv6 PD lifetime. A bit less safe would be to > > say here that the device MUST respect RFC 7772 and only send RAs once > > every few minutes. (The reason that this isn't super safe is that in a > > simple router that just glues together dhcpcd and dnsmasq/radvd, it's > > not easy to implement. The DHCPv6 client and the RA daemon are two > > separate pieces of software written by different authors, so > > transferring the DHCPv6 lifetime to the RA lifetime requires getting the > > two to collaborate.) +Timothy Winters any > > other suggestions? > > FWIW, radvd already supports this, which support implemented by Mark > Smith years ago. > We always see issues between DHCPv6 Client and RA daemon. Fernando, I don;'t think this applies to RA transmission and I will attest to the fact this isn't used by current implementations. When I last looked into this about 30% of CPEs count down lifetimes correctly. The rest transmit the exact value received in the DHCP-PD. I'm not sure what to do about the field changing, as Lorenzo mentions it has become popular on devices to check the RA is the same and drop it for battery sensitive situations. If we have values changing all the time, this will be impossible. > > 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 > --000000000000e94a6b05a2a05ec0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Apr 6, 2020 at 10:09 AM Fernando = Gont <fgont@si6networks.com= > wrote:
Lore= nzo,

On 6/4/20 10:19, Lorenzo Colitti wrote:
> Based on a fair amount of experience with this sort of thing, this > recommendation is risky:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =C2=A0The lifetime values advertised for = prefixes corresponding to a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prefix leased via DHCPv6-PD sh= ould be dynamically updated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(rather than static values), s= ince otherwise the advertised
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lifetimes would eventually spa= n past the DHCPv6-PD lease time..

As noted in the draft, these requirements are already part of RFC4862
and RFC8415. THey are *existing* requirements which are referenced here, because they are of use to solve the problem at hand.

That said, I don't mind adding a reference to RFC7772.


> The safest way to do so would be to remove this text. A bit less safe =
> would be to say that the device must cease to send RAs if the RA
> lifetime is below the DHCPv6 PD lifetime. A bit less safe would be to =
> say here that the device MUST respect RFC 7772 and only send RAs once =
> every few minutes. (The reason that this isn't super safe is that = in a
> simple router that just glues together dhcpcd and dnsmasq/radvd, it= 9;s
> not easy to implement.=C2=A0The DHCPv6 client and the RA daemon are tw= o
> separate pieces of software written by different authors, so
> transferring the DHCPv6 lifetime to the RA lifetime requires getting t= he
> two to collaborate.) +Timothy Winters <mailto:twinters@iol.unh.edu>=C2=A0any =
> other suggestions?

FWIW, radvd already supports this, which support implemented by Mark
Smith years ago.
We always see issues between DHCPv6 C= lient and RA daemon.=C2=A0 Fernando, I don;'t think this applies to RA = transmission and I will attest to the fact this isn't used by current i= mplementations.=C2=A0 When I last looked into this about 30% of CPEs count = down lifetimes correctly.=C2=A0 The rest transmit the exact value received = in the DHCP-PD.=C2=A0 I'm not sure what to do about the field changing,= as Lorenzo mentions it has become popular on devices to check the RA is th= e same and drop it for battery sensitive situations.=C2=A0 If we have value= s changing all the time, this will be impossible.

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
--000000000000e94a6b05a2a05ec0-- From nobody Mon Apr 6 07:53:04 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6BF3A08DD for ; Mon, 6 Apr 2020 07:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUtM2Z9XaCet for ; Mon, 6 Apr 2020 07:52:47 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092203A08F0 for ; Mon, 6 Apr 2020 07:52:44 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jLT7B-0000I4C; Mon, 6 Apr 2020 16:52:41 +0200 Message-Id: To: v6ops@ietf.org Cc: Fernando Gont From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: In-reply-to: Your message of "Sun, 5 Apr 2020 17:23:36 -0300 ." Date: Mon, 06 Apr 2020 16:52:40 +0200 Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 14:52:48 -0000 >On 5/4/20 16:11, Philip Homburg wrote: >> 1) Section 2.1. (Interface Between DHCPv6-PD and SLAAC) >> >> It would be nice have a text like >> 'The router MAY provide an option where the user can override the valid >and >> preferred lifetimes.' >> >> Case in point, my ISP gives me a more or less fixed IPv6 prefix. However >, >> for technical reasons customers have to run DHCPv6-PD. So this leave the >> user with no way to manually configre the lifetimes. > >You mean the router simply copies the lifetimes from dhcpve-pd? Supposed that the ISP sets the lifetime of a prefix to one hour and I want the valid time to be a couple of hours. Then the current text says that the router has to limit the valid lifetime to what remains of one hour. I think there should be a way for operator (user of the CPE) to override this. >1) Something like: PL: Router Lifetime, V:= 1 day -- which seems to be a >very conservative choice that everyone seems to support, or., I think it is a good text and it should have numbers. The numbers here can be tuned to a typical CPE situations. >2) Point to draft-gont-6man-slaac-renum That draft should apply to all hosts, so probably the trade-offs are different. I think it is better to have the discussion here on what are the right values for CPEs. From nobody Mon Apr 6 08:13:39 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17B73A099A for ; Mon, 6 Apr 2020 08:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 aVnIxGdTohyn for ; Mon, 6 Apr 2020 08:13:25 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBBDA3A09A1 for ; Mon, 6 Apr 2020 08:13:24 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 4FACF805EE; Mon, 6 Apr 2020 17:13:21 +0200 (CEST) To: Timothy Winters Cc: Lorenzo Colitti , Ron Bonica , "v6ops@ietf.org" References: From: Fernando Gont Message-ID: <3b0d9b52-e7c5-45cd-bdfc-b8b8f15218a0@si6networks.com> Date: Mon, 6 Apr 2020 12:12:44 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 15:13:27 -0000 On 6/4/20 11:49, Timothy Winters wrote: [....] > > > The safest way to do so would be to remove this text. A bit less > safe > > would be to say that the device must cease to send RAs if the RA > > lifetime is below the DHCPv6 PD lifetime. A bit less safe would > be to > > say here that the device MUST respect RFC 7772 and only send RAs > once > > every few minutes. (The reason that this isn't super safe is that > in a > > simple router that just glues together dhcpcd and dnsmasq/radvd, > it's > > not easy to implement. The DHCPv6 client and the RA daemon are two > > separate pieces of software written by different authors, so > > transferring the DHCPv6 lifetime to the RA lifetime requires > getting the > > two to collaborate.) +Timothy Winters > > any > > other suggestions? > > FWIW, radvd already supports this, which support implemented by Mark > Smith years ago. > > We always see issues between DHCPv6 Client and RA daemon.  Fernando, I > don;'t think this applies to RA transmission and I will attest to the > fact this isn't used by current implementations. Could you elaborate? What specifically doesn't apply to RA transmission? > When I last looked > into this about 30% of CPEs count down lifetimes correctly.  The rest > transmit the exact value received in the DHCP-PD.  I'm not sure what to > do about the field changing, as Lorenzo mentions it has become popular > on devices to check the RA is the same and drop it for battery sensitive > situations.  If we have values changing all the time, this will be > impossible. Note: If CE Routers Advertise the lifetimes as recommended in this document, the RAs will change only for the last "Valid Lifetime" seconds. Or, please let me elaborate in a different way: 1) CE Routers can't just copy the lifetime from DHCPv6-PD, because otherwise, the first second after the first RA is sent, they would be announcing bogus RAs. Say, if the DHCPv6-PD is one month. If you simply copy the lifetime from DHCPv6-PD, then, after 15 days, you'd be advertising a prefix that claims a lifetime 15 longer (double time!) than it really is. 2) Now, if, say, an implementation uses a shorter router lifetime (say, one hour, or the recommended default of 30 minutes), then only the last hour or half hour of the months will the announced PIO lifetimes be incorrect. Thoughts? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 6 08:35:26 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E19E3A0A8E for ; Mon, 6 Apr 2020 08:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qacafe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQUZ5IdBeJpw for ; Mon, 6 Apr 2020 08:35:10 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4563A0ADD for ; Mon, 6 Apr 2020 08:35:00 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id 65so18038715wrl.1 for ; Mon, 06 Apr 2020 08:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rzDT5XX3bRm/EU0ks6NNvZu/mu+d1gavbgpHKHQKESk=; b=nHlG2sYM0X03P0WZiTbk3JeNTDgSa1uoBGdDAbTvVuo8KXsqxkTazwiPl4Ke9EtdaI PRZGHxjt77AcfUHmaoCQ56jFynE1BmZ/K9HjSlDBkPJbcRCymic+gemhOpIHzhTLJDxz 0zF3eAsseOAcb0PQVhSaqWgx/3WHYCke87cZ8= 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=rzDT5XX3bRm/EU0ks6NNvZu/mu+d1gavbgpHKHQKESk=; b=rGIjnAbe4RPfAM04Jd35KFa2SsLdfFdFGhjxUv7j+NvcMPU0DW1N9CxvrXA6dtHy2X ZKoB9nY/8Ys+4y4j73vzda/ROdtq+fV/ao20AN7wR/R2d2Hrdaz/rDQ6y0cAzEflgMY1 KEt8NSRF8XvMJg/9tpISgFJKQXkJHiKlbehRg6oWTQezBnGb2cL0KzvPmI0UmOOsDS3I ds699dXyaPfs4lrqe8ZMyt47Wwallx/E8WTri920UtcYLZMXYQqFmbU5bdd/vZWyTHgC G1gsdTLNksaUH2DkOpMKq3sY4rbcpZn+RLiiBtuEL8dOIlkR3qgKlmtSQBeQGsUAu4BB KuEA== X-Gm-Message-State: AGi0PubKcPOhBzqmqmbeBw6wRns8SULhNmm21IOzbAxaJicWM6Kw5kv6 dQ4YTKVF9EpdZOdcA+VmmGOFPAfs1QOa5MukMr0MtyOm6v0= X-Google-Smtp-Source: APiQypKz5s3BeGb25//nI+36IqzN3jI3rmt8hoIkk44+9bzAb/2inbhqW7sIp0tDo6A6fkBV8M7iXG2pJgEPZ4afOGg= X-Received: by 2002:adf:a1c3:: with SMTP id v3mr6104109wrv.19.1586187298808; Mon, 06 Apr 2020 08:34:58 -0700 (PDT) MIME-Version: 1.0 References: <3b0d9b52-e7c5-45cd-bdfc-b8b8f15218a0@si6networks.com> In-Reply-To: <3b0d9b52-e7c5-45cd-bdfc-b8b8f15218a0@si6networks.com> From: Timothy Winters Date: Mon, 6 Apr 2020 11:34:47 -0400 Message-ID: To: Fernando Gont Cc: Lorenzo Colitti , Ron Bonica , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007e379005a2a10289" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 15:35:14 -0000 --0000000000007e379005a2a10289 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 6, 2020 at 11:13 AM Fernando Gont wrote: > On 6/4/20 11:49, Timothy Winters wrote: > [....] > > > > > The safest way to do so would be to remove this text. A bit less > > safe > > > would be to say that the device must cease to send RAs if the RA > > > lifetime is below the DHCPv6 PD lifetime. A bit less safe would > > be to > > > say here that the device MUST respect RFC 7772 and only send RAs > > once > > > every few minutes. (The reason that this isn't super safe is that > > in a > > > simple router that just glues together dhcpcd and dnsmasq/radvd, > > it's > > > not easy to implement. The DHCPv6 client and the RA daemon are two > > > separate pieces of software written by different authors, so > > > transferring the DHCPv6 lifetime to the RA lifetime requires > > getting the > > > two to collaborate.) +Timothy Winters > > > any > > > other suggestions? > > > > FWIW, radvd already supports this, which support implemented by Mark > > Smith years ago. > > > > We always see issues between DHCPv6 Client and RA daemon. Fernando, I > > don;'t think this applies to RA transmission and I will attest to the > > fact this isn't used by current implementations. > > Could you elaborate? What specifically doesn't apply to RA transmission? > I'm not aware of any prefix/address lifetimes from DHCPv6 affecting RA intervals. > > > > When I last looked > > into this about 30% of CPEs count down lifetimes correctly. The rest > > transmit the exact value received in the DHCP-PD. I'm not sure what to > > do about the field changing, as Lorenzo mentions it has become popular > > on devices to check the RA is the same and drop it for battery sensitive > > situations. If we have values changing all the time, this will be > > impossible. > > Note: If CE Routers Advertise the lifetimes as recommended in this > document, the RAs will change only for the last "Valid Lifetime" seconds. > > Or, please let me elaborate in a different way: > > 1) CE Routers can't just copy the lifetime from DHCPv6-PD, because > otherwise, the first second after the first RA is sent, they would be > announcing bogus RAs. > Say, if the DHCPv6-PD is one month. If you simply copy the lifetime from > DHCPv6-PD, then, after 15 days, you'd be advertising a prefix that > claims a lifetime 15 longer (double time!) than it really is. > > 2) Now, if, say, an implementation uses a shorter router lifetime (say, > one hour, or the recommended default of 30 minutes), then only the last > hour or half hour of the months will the announced PIO lifetimes be > incorrect. > > Thoughts? > Did you mean valid lifetime or router lifetime? > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --0000000000007e379005a2a10289 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 6, 2020 at 11:13 AM Ferna= ndo Gont <fgont@si6networks.com= > wrote:
= On 6/4/20 11:49, Timothy Winters wrote:
[....]
>
>=C2=A0 =C2=A0 =C2=A0 > The safest way to do so would be to remove th= is text. A bit less
>=C2=A0 =C2=A0 =C2=A0safe
>=C2=A0 =C2=A0 =C2=A0 > would be to say that the device must cease to= send RAs if the RA
>=C2=A0 =C2=A0 =C2=A0 > lifetime is below the DHCPv6 PD lifetime. A b= it less safe would
>=C2=A0 =C2=A0 =C2=A0be to
>=C2=A0 =C2=A0 =C2=A0 > say here that the device MUST respect RFC 777= 2 and only send RAs
>=C2=A0 =C2=A0 =C2=A0once
>=C2=A0 =C2=A0 =C2=A0 > every few minutes. (The reason that this isn&= #39;t super safe is that
>=C2=A0 =C2=A0 =C2=A0in a
>=C2=A0 =C2=A0 =C2=A0 > simple router that just glues together dhcpcd= and dnsmasq/radvd,
>=C2=A0 =C2=A0 =C2=A0it's
>=C2=A0 =C2=A0 =C2=A0 > not easy to implement.=C2=A0The DHCPv6 client= and the RA daemon are two
>=C2=A0 =C2=A0 =C2=A0 > separate pieces of software written by differ= ent authors, so
>=C2=A0 =C2=A0 =C2=A0 > transferring the DHCPv6 lifetime to the RA li= fetime requires
>=C2=A0 =C2=A0 =C2=A0getting the
>=C2=A0 =C2=A0 =C2=A0 > two to collaborate.) +Timothy Winters
>=C2=A0 =C2=A0 =C2=A0<mailto:twinters@iol.unh.edu <mailto:twinters@iol.unh.edu>>=C2=A0= any
>=C2=A0 =C2=A0 =C2=A0 > other suggestions?
>
>=C2=A0 =C2=A0 =C2=A0FWIW, radvd already supports this, which support im= plemented by Mark
>=C2=A0 =C2=A0 =C2=A0Smith years ago.
>
> We always see issues between DHCPv6 Client and RA daemon.=C2=A0 Fernan= do, I
> don;'t think this applies to RA transmission and I will attest to = the
> fact this isn't used by current implementations.

Could you elaborate? What specifically doesn't apply to RA transmission= ?
I'm not aware of any prefix/address lifetimes fr= om DHCPv6 affecting RA intervals.=C2=A0


> When I last looked
> into this about 30% of CPEs count down lifetimes correctly.=C2=A0 The = rest
> transmit the exact value received in the DHCP-PD.=C2=A0 I'm not su= re what to
> do about the field changing, as Lorenzo mentions it has become popular=
> on devices to check the RA is the same and drop it for battery sensiti= ve
> situations.=C2=A0 If we have values changing all the time, this will b= e
> impossible.

Note: If CE Routers Advertise the lifetimes as recommended in this
document, the RAs will change only for the last "Valid Lifetime" = seconds.

Or, please let me elaborate in a different way:

1) CE Routers can't just copy the lifetime from DHCPv6-PD, because
otherwise, the first second after the first RA is sent, they would be
announcing bogus RAs.
Say, if the DHCPv6-PD is one month. If you simply copy the lifetime from DHCPv6-PD, then, after 15 days, you'd be advertising a prefix that
claims a lifetime 15 longer (double time!) than it really is.

2) Now, if, say, an implementation uses a shorter router lifetime (say, one hour, or the recommended default of 30 minutes), then only the last hour or half hour of the months will the announced PIO lifetimes be
incorrect.

Thoughts?
Did you mean valid lifetime or router lifeti= me?=C2=A0

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




--0000000000007e379005a2a10289-- From nobody Mon Apr 6 08:40:38 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC413A0B19 for ; Mon, 6 Apr 2020 08:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOVsoAIK03BY for ; Mon, 6 Apr 2020 08:40:15 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30FDA3A0AEC for ; Mon, 6 Apr 2020 08:40:15 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 D029D808C3; Mon, 6 Apr 2020 17:40:12 +0200 (CEST) To: Philip Homburg , v6ops@ietf.org References: From: Fernando Gont Message-ID: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> Date: Mon, 6 Apr 2020 12:33:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 15:40:17 -0000 On 6/4/20 11:52, Philip Homburg wrote: >> On 5/4/20 16:11, Philip Homburg wrote: >>> 1) Section 2.1. (Interface Between DHCPv6-PD and SLAAC) >>> >>> It would be nice have a text like >>> 'The router MAY provide an option where the user can override the valid >> and >>> preferred lifetimes.' >>> >>> Case in point, my ISP gives me a more or less fixed IPv6 prefix. However >> , >>> for technical reasons customers have to run DHCPv6-PD. So this leave the >>> user with no way to manually configre the lifetimes. >> >> You mean the router simply copies the lifetimes from dhcpve-pd? > > Supposed that the ISP sets the lifetime of a prefix to one hour and I want > the valid time to be a couple of hours. Then the current text says that > the router has to limit the valid lifetime to what remains of one hour. > > I think there should be a way for operator (user of the CPE) to override this. I don't mind a CE Router to have knobs for folks to play with (in fact, that's normally useful). That said, setting, the PIO lifetimes in a way that would span past the DHCPV6-PD would be incorrect. >> 1) Something like: PL: Router Lifetime, V:= 1 day -- which seems to be a >> very conservative choice that everyone seems to support, or., > > I think it is a good text and it should have numbers. The numbers here can > be tuned to a typical CPE situations. So, double-checking: you agree to we incorporate the text that I proposed, and that we suggest the PL: Router Lifetime, and VL: 1 days? >> 2) Point to draft-gont-6man-slaac-renum > > That draft should apply to all hosts, so probably the trade-offs are > different. I think it is better to have the discussion here on what are the > right values for CPEs. Makes sense. 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 Mon Apr 6 09:01:08 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E393A0B57 for ; Mon, 6 Apr 2020 09:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDyMoTCxgBmc for ; Mon, 6 Apr 2020 09:00:49 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E4B3A0AC1 for ; Mon, 6 Apr 2020 09:00:48 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79d:53aa:d30:a802:1264:bb16:f7ba]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 2A5284E11B6D; Mon, 6 Apr 2020 16:00:48 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 08E4A3153FF8; Mon, 6 Apr 2020 18:00:42 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> Date: Mon, 6 Apr 2020 18:00:41 +0200 Cc: Philip Homburg , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 16:00:50 -0000 >>>> 1) Section 2.1. (Interface Between DHCPv6-PD and SLAAC) >>>>=20 >>>> It would be nice have a text like >>>> 'The router MAY provide an option where the user can override = the valid >>> and >>>> preferred lifetimes.' >>>>=20 >>>> Case in point, my ISP gives me a more or less fixed IPv6 = prefix. However >>> , >>>> for technical reasons customers have to run DHCPv6-PD. So this = leave the >>>> user with no way to manually configre the lifetimes. >>>=20 >>> You mean the router simply copies the lifetimes from dhcpve-pd? >> Supposed that the ISP sets the lifetime of a prefix to one hour and I = want >> the valid time to be a couple of hours. Then the current text says = that >> the router has to limit the valid lifetime to what remains of one = hour. >> I think there should be a way for operator (user of the CPE) to = override this. >=20 > I don't mind a CE Router to have knobs for folks to play with (in = fact, that's normally useful). >=20 > That said, setting, the PIO lifetimes in a way that would span past = the DHCPV6-PD would be incorrect. Yes, that would violate a fundamental premise of prefix delegation. Cheers, Ole= From nobody Mon Apr 6 09:03:17 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581483A0B80 for ; Mon, 6 Apr 2020 09:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzkCK7DRMS2w for ; Mon, 6 Apr 2020 09:02:59 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77E73A0B66 for ; Mon, 6 Apr 2020 09:02:46 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79d:53aa:d30:a802:1264:bb16:f7ba]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 858B04E11B0A; Mon, 6 Apr 2020 16:02:46 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 4FE2A31540FC; Mon, 6 Apr 2020 18:02:41 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> Date: Mon, 6 Apr 2020 18:02:41 +0200 Cc: Philip Homburg , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 16:03:00 -0000 >>> 1) Something like: PL: Router Lifetime, V:=3D 1 day -- which seems = to be a >>> very conservative choice that everyone seems to support, or., >> I think it is a good text and it should have numbers. The numbers = here can >> be tuned to a typical CPE situations. >=20 > So, double-checking: you agree to we incorporate the text that I = proposed, and that we suggest the PL: Router Lifetime, and VL: 1 days? I would object to this document proposing new default lifetimes. The RA should advertise the lifetimes towards an exiry date as described = in 4861. Let's not let this document feature creep. It's there to solve one = problem and one problem only. Cheers, Ole= From nobody Mon Apr 6 09:06:52 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397533A0B85 for ; Mon, 6 Apr 2020 09:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNMN9AJyOm52 for ; Mon, 6 Apr 2020 09:06:37 -0700 (PDT) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54ED03A0B80 for ; Mon, 6 Apr 2020 09:06:37 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id p60so196371qva.5 for ; Mon, 06 Apr 2020 09:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=x9WUJ6Z6URI+SM5737qkjYe+AK/SdeI8CEae+Wrd/7w=; b=JrILmFHUqY0VtH/IEBdMQH8Yhhwq99jDawNoO3Pq3Lm4vP+3XVtaHECZlXiaE+kQuq ikn/+QInE+ZR6NGed0u1iUvKzhnM+KYYn1K3DeFfIgzb1viu2Z4uth2Xp0g6n2b4Zf+S ZYzBkC4gWvI8lXhV0OlVe9FonlqzIfxnAqdhFBUe7kBlfDnC/ehHzoajcpvkVSlPs+p4 zsqY2JC9+h/EHS0mL1ykiN9Vu/Io8L64PNWFKZYXtA4xRNNLsuqqJU2cvozysKPspmzo I9lRnTtGFDGS5Q5ICBAynB6dCOG4ErlJO1eMBPxOroPkpKk9spwE3g+AZiEBxLKCvANs vo8Q== 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=x9WUJ6Z6URI+SM5737qkjYe+AK/SdeI8CEae+Wrd/7w=; b=JLVRl9B3Z7FHOkNxVV18b9rBrzP+861oaeuJDWz7rKe44+G8VzKwHplAU7AY0K9thN KD8FXHgHYnVxEuGmpPaYODhM+HKTceNsXybY3uHaHioWsw3d29vjHef+OMM2BhcGCJmk dAp91RLGz2TtxmzBUnXU86TGgZkoi6Iimj2VfDBH/o61DGWv6/MPWSSFj6f0yGQpS5XQ PU0CPSTpqrzo7+cAL+SlrBx0DBQ+ku/dTlHwj1jglqJKxfsxzwM5lFHlpmtN9nGRr44F rChCPoX2I5i5gqtucddznj4DFMnLvm1idT5HNTrYaiOjIihChHDP+0yp/NnzKgzH1mke z6bA== X-Gm-Message-State: AGi0PuaIzfLojREjyPe7pf9uaDw2Hyjp/ghGFdM9cK3idbjqxC1dycHR UelWIFcxecwdPJT3uiTCsytMks7IW5A= X-Google-Smtp-Source: APiQypJTIpO+Bn1rKpm4fjn4kkUA0AC06axAPvxyN1WwfGO40cVSMVM/uOVgIBOdS8SqjlNYdLOEHA== X-Received: by 2002:a05:6214:1414:: with SMTP id n20mr371520qvx.160.1586189196439; Mon, 06 Apr 2020 09:06:36 -0700 (PDT) Received: from [192.168.1.241] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id o11sm15364341qtb.24.2020.04.06.09.06.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Apr 2020 09:06:36 -0700 (PDT) From: Ted Lemon Message-Id: <9D35632D-608C-41E0-BC3F-93663F6AA433@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1619C501-55F3-4DAD-B3C9-39D36E811C70" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.6\)) Date: Mon, 6 Apr 2020 12:06:32 -0400 In-Reply-To: Cc: v6ops@ietf.org, Fernando Gont To: Philip Homburg References: X-Mailer: Apple Mail (2.3622.0.6) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 16:06:39 -0000 --Apple-Mail=_1619C501-55F3-4DAD-B3C9-39D36E811C70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 6, 2020, at 10:52 AM, Philip Homburg = wrote: > Supposed that the ISP sets the lifetime of a prefix to one hour and I = want=20 > the valid time to be a couple of hours. Then the current text says = that > the router has to limit the valid lifetime to what remains of one = hour. Why would you want the valid lifetime to be longer than the actual valid = lifetime? On Apr 6, 2020, at 10:25 AM, Bernie Volz (volz) = wrote: > The question is how long this information has to be remembered and = sent to the client. I don't think RFC8415 is that clear on this issue. Isn=E2=80=99t the server supposed to remember the prefix it has assigned = until its valid lifetime expires? --Apple-Mail=_1619C501-55F3-4DAD-B3C9-39D36E811C70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Apr 6, 2020, at 10:52 AM, Philip Homburg <pch-v6ops-9@u-1.phicoh.com> wrote:
Supposed that the ISP sets the lifetime of a prefix to one = hour and I = want 
the valid time to be a couple of = hours. Then the = current text says that
the router has to limit the valid lifetime to what remains of = one hour.

Why would you want the valid lifetime to be longer than the = actual valid lifetime?

On Apr 6, 2020, at 10:25 AM, Bernie Volz (volz) <volz=3D40cisco.com@dmarc.ietf.org> wrote:
The question is how long this information has to be = remembered and sent to the client. I don't think RFC8415 is that clear = on this issue.

Isn=E2=80=99t the server supposed to = remember the prefix it has assigned until its valid lifetime = expires?

= --Apple-Mail=_1619C501-55F3-4DAD-B3C9-39D36E811C70-- From nobody Mon Apr 6 09:09:09 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE763A0BAC for ; Mon, 6 Apr 2020 09:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 bLGFEs2-GDFN for ; Mon, 6 Apr 2020 09:08:48 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9F93A0AEF for ; Mon, 6 Apr 2020 09:08:22 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79d:53aa:d30:a802:1264:bb16:f7ba]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 956634E11AEC; Mon, 6 Apr 2020 16:08:22 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id A1EC5315441C; Mon, 6 Apr 2020 18:08:17 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Mon, 6 Apr 2020 18:08:17 +0200 Cc: Ron Bonica , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6186B94B-2504-48C7-8A20-AEB5896D1BB1@employees.org> References: <52688D39-5537-44BA-B1C8-4341C21D1B02@employees.org> To: Bernie Volz X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 16:08:52 -0000 Bernie, > The question is how long this information has to be remembered and = sent to the client. I don't think RFC8415 is that clear on this issue. RFC8415 doesn't seem to say much about renumbering at all. I guess from = its perspective it's all operational. > Yes, when the old PD is switched to a new PD, the server would be = expected to send the old PD with 0 lifetimes. But how long will the = server remember this is the key question and, for example if 30 days = were remaining on the old PD, it should keep sending it for 30 days. I don't think that necessarily follows. The delegating server is allowed to change the lifetimes of the old = prefix, so I would imagine it was only necessary to include the old = prefix in one DHCP exchange. > If you read the text of the proposed draft, it only puts a requirement = on the CPE: >=20 > 2.2. Signaling Stale Configuration Information >=20 > In order to phase-out stale configuration information: >=20 > o A CE router sending RAs that advertise dynamically-learned > prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on > stable storage, the list of prefixes being advertised on each > network segment, and the "A" and "L" flags of the corresponding > PIOs. Yes, and as I said that's a band-aid for a broken deployment. And suggested that a paragraph explaining the correct renumbering = procedure was added. To avoid confusion. Not all CPEs are ever going to do this anyway.=20 Best regards, Ole= From nobody Mon Apr 6 09:38:26 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F803A080B for ; Mon, 6 Apr 2020 09:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTwNN22LFqEL for ; Mon, 6 Apr 2020 09:38:11 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FFC3A07AC for ; Mon, 6 Apr 2020 09:38:10 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 444F8805BE; Mon, 6 Apr 2020 18:38:07 +0200 (CEST) To: Timothy Winters Cc: Lorenzo Colitti , Ron Bonica , "v6ops@ietf.org" References: <3b0d9b52-e7c5-45cd-bdfc-b8b8f15218a0@si6networks.com> From: Fernando Gont Message-ID: Date: Mon, 6 Apr 2020 12:50:50 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 16:38:13 -0000 On 6/4/20 12:34, Timothy Winters wrote: [...] > Could you elaborate? What specifically doesn't apply to RA transmission? > > I'm not aware of any prefix/address lifetimes from DHCPv6 affecting RA > intervals. So, what happens if, say, the DHCPv6-PD is, say, two months? The set the Valid/Prefix Lifetime of PIOs to that value? > > Note: If CE Routers Advertise the lifetimes as recommended in this > document, the RAs will change only for the last "Valid Lifetime" > seconds. > > Or, please let me elaborate in a different way: > > 1) CE Routers can't just copy the lifetime from DHCPv6-PD, because > otherwise, the first second after the first RA is sent, they would be > announcing bogus RAs. > Say, if the DHCPv6-PD is one month. If you simply copy the lifetime > from > DHCPv6-PD, then, after 15 days, you'd be advertising a prefix that > claims a lifetime 15 longer (double time!) than it really is. > > 2) Now, if, say, an implementation uses a shorter router lifetime (say, > one hour, or the recommended default of 30 minutes), then only the last > hour or half hour of the months will the announced PIO lifetimes be > incorrect. > > Thoughts? > > Did you mean valid lifetime or router lifetime? I meant: "If the implementations always set the PIO Valid Lifetime to the Router Lifetime, as suggested in draft-gont-6man-slaac-renum". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 6 10:18:38 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C857B3A0B12 for ; Mon, 6 Apr 2020 10:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nr8wuMdgK9j for ; Mon, 6 Apr 2020 10:18:15 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C255E3A0B08 for ; Mon, 6 Apr 2020 10:18:14 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 9E90582C48; Mon, 6 Apr 2020 19:18:11 +0200 (CEST) To: otroan@employees.org, Bernie Volz Cc: Ron Bonica , "v6ops@ietf.org" References: <52688D39-5537-44BA-B1C8-4341C21D1B02@employees.org> <6186B94B-2504-48C7-8A20-AEB5896D1BB1@employees.org> From: Fernando Gont Message-ID: <56667bf5-97ac-5427-6d75-7ff4f32bf946@si6networks.com> Date: Mon, 6 Apr 2020 14:00:29 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <6186B94B-2504-48C7-8A20-AEB5896D1BB1@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 17:18:17 -0000 Hi, Ole, On 6/4/20 13:08, otroan@employees.org wrote: [...] >> Yes, when the old PD is switched to a new PD, the server would be expected to send the old PD with 0 lifetimes. But how long will the server remember this is the key question and, for example if 30 days were remaining on the old PD, it should keep sending it for 30 days. > > I don't think that necessarily follows. > The delegating server is allowed to change the lifetimes of the old prefix, so I would imagine it was only necessary to include the old prefix in one DHCP exchange. Since the DHCPv6-PD client could come back anytime withing the DHCPv6-PD lease time of the stale prefix, the DHCPv6 server would need to remember this for such period of time. I assume that's what Bernie meant. >> If you read the text of the proposed draft, it only puts a requirement on the CPE: >> >> 2.2. Signaling Stale Configuration Information >> >> In order to phase-out stale configuration information: >> >> o A CE router sending RAs that advertise dynamically-learned >> prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on >> stable storage, the list of prefixes being advertised on each >> network segment, and the "A" and "L" flags of the corresponding >> PIOs. > > Yes, and as I said that's a band-aid for a broken deployment. > And suggested that a paragraph explaining the correct renumbering procedure was added. To avoid confusion. > Not all CPEs are ever going to do this anyway. How about adding this: IPv6 network renumbering is expected to take place in a planned manner, with old/stale prefixes being phased-out via reduced prefix lifetimes while new prefixes (with normal lifetimes) are introduced. However, there are a number of scenarios that may lead to the so- called "flash-renumbering" events, where the prefix being employed on a network suddenly becomes invalid and replaced by a new prefix [I-D.ietf-v6ops-slaac-renum]. One of such scenarios is that in which a DHCPv6-server employs dynamic prefixes, and the Customer Edge Router crashes and reboots. The requirement in this section is meant to allow Customer Edge Routers to deprecate stale information in such scenarios. to the RATIONALE in Section 2.2? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 6 10:27:02 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E943A0CA0 for ; Mon, 6 Apr 2020 10:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiBnDKVo3KJu for ; Mon, 6 Apr 2020 10:26:44 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCB53A0C9B for ; Mon, 6 Apr 2020 10:26:44 -0700 (PDT) Received: from [IPv6:2a01:79d:53aa:d30:68d4:67e1:7951:ee73] (unknown [IPv6:2a01:79d:53aa:d30:68d4:67e1:7951:ee73]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 991D84E11BA0; Mon, 6 Apr 2020 17:26:43 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Mon, 6 Apr 2020 19:26:40 +0200 Message-Id: References: <56667bf5-97ac-5427-6d75-7ff4f32bf946@si6networks.com> Cc: Bernie Volz , Ron Bonica , "v6ops@ietf.org" In-Reply-To: <56667bf5-97ac-5427-6d75-7ff4f32bf946@si6networks.com> To: Fernando Gont X-Mailer: iPhone Mail (17E255) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 17:26:46 -0000 Hi Fernando, That text works for me.=20 Cheers=20 Ole > On 6 Apr 2020, at 19:18, Fernando Gont wrote: >=20 > =EF=BB=BFHi, Ole, >=20 > On 6/4/20 13:08, otroan@employees.org wrote: > [...] >>> Yes, when the old PD is switched to a new PD, the server would be expect= ed to send the old PD with 0 lifetimes. But how long will the server remembe= r this is the key question and, for example if 30 days were remaining on the= old PD, it should keep sending it for 30 days. >> I don't think that necessarily follows. >> The delegating server is allowed to change the lifetimes of the old prefi= x, so I would imagine it was only necessary to include the old prefix in one= DHCP exchange. >=20 > Since the DHCPv6-PD client could come back anytime withing the DHCPv6-PD l= ease time of the stale prefix, the DHCPv6 server would need to remember this= for such period of time. I assume that's what Bernie meant. >=20 >=20 >=20 >>> If you read the text of the proposed draft, it only puts a requirement o= n the CPE: >>>=20 >>> 2.2. Signaling Stale Configuration Information >>>=20 >>> In order to phase-out stale configuration information: >>>=20 >>> o A CE router sending RAs that advertise dynamically-learned >>> prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on >>> stable storage, the list of prefixes being advertised on each >>> network segment, and the "A" and "L" flags of the corresponding >>> PIOs. >> Yes, and as I said that's a band-aid for a broken deployment. >> And suggested that a paragraph explaining the correct renumbering procedu= re was added. To avoid confusion. >> Not all CPEs are ever going to do this anyway. >=20 > How about adding this: > IPv6 network renumbering is expected to take place in a planned > manner, with old/stale prefixes being phased-out via reduced prefix > lifetimes while new prefixes (with normal lifetimes) are introduced. > However, there are a number of scenarios that may lead to the so- > called "flash-renumbering" events, where the prefix being employed on > a network suddenly becomes invalid and replaced by a new prefix > [I-D.ietf-v6ops-slaac-renum]. One of such scenarios is that in which > a DHCPv6-server employs dynamic prefixes, and the Customer Edge > Router crashes and reboots. The requirement in this section is meant > to allow Customer Edge Routers to deprecate stale information in such > scenarios. >=20 > to the RATIONALE in Section 2.2? >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From nobody Mon Apr 6 12:08:34 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529563A0908 for ; Mon, 6 Apr 2020 12:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 jQmfbRg-4FSD for ; Mon, 6 Apr 2020 12:08:31 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D9D3A091E for ; Mon, 6 Apr 2020 12:08:30 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 4F53982C48; Mon, 6 Apr 2020 21:03:16 +0200 (CEST) To: otroan@employees.org, Lorenzo Colitti Cc: Ron Bonica , "v6ops@ietf.org" References: From: Fernando Gont Message-ID: <55943c3d-cbf0-a390-c0ee-e2578e664ebb@si6networks.com> Date: Mon, 6 Apr 2020 14:48:15 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 19:08:32 -0000 On 6/4/20 10:47, otroan@employees.org wrote: >> Has this text: >> >> o A CE router sending RAs that advertise dynamically-learned >> prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on >> stable storage, the list of prefixes being advertised on each >> network segment, and the "A" and "L" flags of the corresponding >> PIOs. >> >> been run past manufacturers of home gateways? Depending on how write many cycles the flash allows, and on how low the prefix lifetimes are, this might not be feasible on real products. > > ah, yes this was the comment I forgot. > This issue was brought up multiple times. The text has to be losened and more explanatory. Cause this is a no-go for lots of devices without persistent storage. How about changing this requirement to "SHOULD", and add this note to the RATIONALE of the corresponding section: "The requirement in this section is conveyed as a "SHOULD" (as opposed to a "MUST"), since we acknowledge that the availability of stable storage to record the information may represent a challenge for some implementations." ? 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 Mon Apr 6 12:21:00 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BB23A0A5D for ; Mon, 6 Apr 2020 12:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 EnEVTqkeuWti for ; Mon, 6 Apr 2020 12:20:57 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6821B3A0A55 for ; Mon, 6 Apr 2020 12:20:57 -0700 (PDT) Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 546194E11BF6; Mon, 6 Apr 2020 19:20:56 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 9F6943156773; Mon, 6 Apr 2020 21:20:50 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Mon, 6 Apr 2020 21:20:50 +0200 Cc: Timothy Winters , Ron Bonica , "v6ops@ietf.org" , Lorenzo Colitti Content-Transfer-Encoding: quoted-printable Message-Id: <2EB56B98-8267-4F1F-B558-BE6DC28CA61E@employees.org> References: <3b0d9b52-e7c5-45cd-bdfc-b8b8f15218a0@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 19:20:59 -0000 >> Could you elaborate? What specifically doesn't apply to RA = transmission? >> I'm not aware of any prefix/address lifetimes from DHCPv6 affecting = RA intervals. >=20 > So, what happens if, say, the DHCPv6-PD is, say, two months? The set = the Valid/Prefix Lifetime of PIOs to that value? Yes, counting down in real time: As specified in 4861: 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, Ole= From nobody Mon Apr 6 12:25:31 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D7C3A0AB8 for ; Mon, 6 Apr 2020 12:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qacafe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxUFhlSYUZXW for ; Mon, 6 Apr 2020 12:25:27 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450: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 2FCAA3A0ABE for ; Mon, 6 Apr 2020 12:25:27 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id c15so846244wro.11 for ; Mon, 06 Apr 2020 12:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Tj2HKzHgXtN/6/+3DA+1GaiojHnBQ2rPJBNIqwSmUQ=; b=FCazb/8+UG2gAI+unRPYgnuwRlFrP3MjZQK/IeYwEPKSlKpDByy6AyyJOOsaROfNEQ 3VTJgu3Ok351yFOdh3aC79Vcr7Ncy68LcVAY5kfQFU+c/1VK4cvXpL1xQCwm6Q1zkeiO S0IwdsZBq2dpE2GW+WD82owZ/iToRyYktfEPM= 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=4Tj2HKzHgXtN/6/+3DA+1GaiojHnBQ2rPJBNIqwSmUQ=; b=dA/k0TaD/k8v3ce/1oo3BO46H5yvkZMFK8csFB1QXX1JQd2a/+M3x31+eKLg1pwmcM vBkuFWa5RnlNcL0QKXPIGnF4dxIIywbFp8tETQ5aEk7DtH7lhGe03PbnPV5VquaKXkTh ehLVLs2NLgzS8/RNrsa/x5u4BctRLfOuvyznuTCtF+VpqGvfAKK27Q2d2iXh7TEB3Pa6 kZbU0or95BmiB77IRxN+pTwdTqeIkPUyh5VZODpfxI+ew/XM8Wl1zvUcaMKKXGfN9rn8 eXybiDkjusVh0uDWe6iMpowX0uaf1Hcaizbdgw24uxZaCOyoqt68l/jKv5vtSfYmkHnh PGbA== X-Gm-Message-State: AGi0PuaUYlEnS6DKe17hJuurl+Np17ZriDh8T4tfKxIaxON69hS2Frut q0c75IWDP+uTEqnoClYIBiZxSOXOhDR2n0zAMNZJBRAYU+I= X-Google-Smtp-Source: APiQypJNcDFWGKKXBweCJOpG4Ew/mkAsC35TSYAHAu+aRzttUmdpugNacpCgpDe24XsgBbHVhHup4q2sE+KAAC9q9GM= X-Received: by 2002:adf:a1c3:: with SMTP id v3mr799746wrv.19.1586201118455; Mon, 06 Apr 2020 12:25:18 -0700 (PDT) MIME-Version: 1.0 References: <3b0d9b52-e7c5-45cd-bdfc-b8b8f15218a0@si6networks.com> In-Reply-To: From: Timothy Winters Date: Mon, 6 Apr 2020 15:25:07 -0400 Message-ID: To: Fernando Gont Cc: Lorenzo Colitti , Ron Bonica , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000354d4705a2a43aed" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 19:25:29 -0000 --000000000000354d4705a2a43aed Content-Type: text/plain; charset="UTF-8" On Mon, Apr 6, 2020 at 12:38 PM Fernando Gont wrote: > On 6/4/20 12:34, Timothy Winters wrote: > [...] > > Could you elaborate? What specifically doesn't apply to RA > transmission? > > > > I'm not aware of any prefix/address lifetimes from DHCPv6 affecting RA > > intervals. > > So, what happens if, say, the DHCPv6-PD is, say, two months? The set the > Valid/Prefix Lifetime of PIOs to that value? > Yes at the moment. > > > > > > Note: If CE Routers Advertise the lifetimes as recommended in this > > document, the RAs will change only for the last "Valid Lifetime" > > seconds. > > > > Or, please let me elaborate in a different way: > > > > 1) CE Routers can't just copy the lifetime from DHCPv6-PD, because > > otherwise, the first second after the first RA is sent, they would be > > announcing bogus RAs. > > Say, if the DHCPv6-PD is one month. If you simply copy the lifetime > > from > > DHCPv6-PD, then, after 15 days, you'd be advertising a prefix that > > claims a lifetime 15 longer (double time!) than it really is. > > > > 2) Now, if, say, an implementation uses a shorter router lifetime > (say, > > one hour, or the recommended default of 30 minutes), then only the > last > > hour or half hour of the months will the announced PIO lifetimes be > > incorrect. > > > > Thoughts? > > > > Did you mean valid lifetime or router lifetime? > > I meant: "If the implementations always set the PIO Valid Lifetime to > the Router Lifetime, as suggested in draft-gont-6man-slaac-renum". Right, the thing that concerns me about this is CPEs use all kinds of interesting values for router lifetime. I guess it's a smaller value by definition (9000 seconds). > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --000000000000354d4705a2a43aed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 6, 2020 at 12:38 PM Ferna= ndo Gont <fgo= nt@si6networks.com> wrote:
On 6/4/20 12:34, Timothy Winters wrote:
[...]
>=C2=A0 =C2=A0 =C2=A0Could you elaborate? What specifically doesn't = apply to RA transmission?
>
> I'm not aware of any prefix/address lifetimes from DHCPv6 affectin= g RA
> intervals.

So, what happens if, say, the DHCPv6-PD is, say, two months? The set the Valid/Prefix Lifetime of PIOs to that value?
=C2=A0Yes= at the moment.


>
>=C2=A0 =C2=A0 =C2=A0Note: If CE Routers Advertise the lifetimes as reco= mmended in this
>=C2=A0 =C2=A0 =C2=A0document, the RAs will change only for the last &qu= ot;Valid Lifetime"
>=C2=A0 =C2=A0 =C2=A0seconds.
>
>=C2=A0 =C2=A0 =C2=A0Or, please let me elaborate in a different way:
>
>=C2=A0 =C2=A0 =C2=A01) CE Routers can't just copy the lifetime from= DHCPv6-PD, because
>=C2=A0 =C2=A0 =C2=A0otherwise, the first second after the first RA is s= ent, they would be
>=C2=A0 =C2=A0 =C2=A0announcing bogus RAs.
>=C2=A0 =C2=A0 =C2=A0Say, if the DHCPv6-PD is one month. If you simply c= opy the lifetime
>=C2=A0 =C2=A0 =C2=A0from
>=C2=A0 =C2=A0 =C2=A0DHCPv6-PD, then, after 15 days, you'd be advert= ising a prefix that
>=C2=A0 =C2=A0 =C2=A0claims a lifetime 15 longer (double time!) than it = really is.
>
>=C2=A0 =C2=A0 =C2=A02) Now, if, say, an implementation uses a shorter r= outer lifetime (say,
>=C2=A0 =C2=A0 =C2=A0one hour, or the recommended default of 30 minutes)= , then only the last
>=C2=A0 =C2=A0 =C2=A0hour or half hour of the months will the announced = PIO lifetimes be
>=C2=A0 =C2=A0 =C2=A0incorrect.
>
>=C2=A0 =C2=A0 =C2=A0Thoughts?
>
> Did you mean valid lifetime or router lifetime?

I meant: "If the implementations always set the PIO Valid Lifetime to =
the Router Lifetime, as suggested in draft-gont-6man-slaac-renum".=C2= =A0
Right, the thing that concerns me about this is CPEs u= se all kinds of interesting values for router lifetime.=C2=A0 I guess it= 9;s a smaller value by definition (9000 seconds).

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




--000000000000354d4705a2a43aed-- From nobody Mon Apr 6 12:53:40 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1651F3A0DEB for ; Mon, 6 Apr 2020 12:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 UJfOc_RYN2J6 for ; Mon, 6 Apr 2020 12:53:31 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2333A0DE8 for ; Mon, 6 Apr 2020 12:53:30 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 4F69382D71; Mon, 6 Apr 2020 21:45:39 +0200 (CEST) To: otroan@employees.org Cc: Timothy Winters , Ron Bonica , "v6ops@ietf.org" , Lorenzo Colitti References: <3b0d9b52-e7c5-45cd-bdfc-b8b8f15218a0@si6networks.com> <2EB56B98-8267-4F1F-B558-BE6DC28CA61E@employees.org> From: Fernando Gont Message-ID: Date: Mon, 6 Apr 2020 16:31:42 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <2EB56B98-8267-4F1F-B558-BE6DC28CA61E@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 19:53:38 -0000 On 6/4/20 16:20, otroan@employees.org wrote: >>> Could you elaborate? What specifically doesn't apply to RA transmission? >>> I'm not aware of any prefix/address lifetimes from DHCPv6 affecting RA intervals. >> >> So, what happens if, say, the DHCPv6-PD is, say, two months? The set the Valid/Prefix Lifetime of PIOs to that value? > > Yes, counting down in real time: > > As specified in 4861: [...] Yes. That's what I meant, and what also RFC8415 requires. But LOrenzo was arguing against... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 6 12:53:43 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D1F3A0DE8 for ; Mon, 6 Apr 2020 12:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3GayLdECbsK for ; Mon, 6 Apr 2020 12:53:31 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007F73A0DEA for ; Mon, 6 Apr 2020 12:53:30 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 CFDBF83214; Mon, 6 Apr 2020 21:45:43 +0200 (CEST) To: Timothy Winters Cc: Lorenzo Colitti , Ron Bonica , "v6ops@ietf.org" References: <3b0d9b52-e7c5-45cd-bdfc-b8b8f15218a0@si6networks.com> From: Fernando Gont Message-ID: Date: Mon, 6 Apr 2020 16:37:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 19:53:38 -0000 On 6/4/20 16:25, Timothy Winters wrote: > > > On Mon, Apr 6, 2020 at 12:38 PM Fernando Gont > wrote: > > On 6/4/20 12:34, Timothy Winters wrote: > [...] > >     Could you elaborate? What specifically doesn't apply to RA > transmission? > > > > I'm not aware of any prefix/address lifetimes from DHCPv6 > affecting RA > > intervals. > > So, what happens if, say, the DHCPv6-PD is, say, two months? The set > the > Valid/Prefix Lifetime of PIOs to that value? > >  Yes at the moment. What lifetime do they use for the PIOs say, 15 days after receiving the one-month lease? Still 30 days? -- that seems very broken. And yet another way for these problems to appear. > >     Note: If CE Routers Advertise the lifetimes as recommended in > this > >     document, the RAs will change only for the last "Valid Lifetime" > >     seconds. > > > >     Or, please let me elaborate in a different way: > > > >     1) CE Routers can't just copy the lifetime from DHCPv6-PD, > because > >     otherwise, the first second after the first RA is sent, they > would be > >     announcing bogus RAs. > >     Say, if the DHCPv6-PD is one month. If you simply copy the > lifetime > >     from > >     DHCPv6-PD, then, after 15 days, you'd be advertising a prefix > that > >     claims a lifetime 15 longer (double time!) than it really is. > > > >     2) Now, if, say, an implementation uses a shorter router > lifetime (say, > >     one hour, or the recommended default of 30 minutes), then > only the last > >     hour or half hour of the months will the announced PIO > lifetimes be > >     incorrect. > > > >     Thoughts? > > > > Did you mean valid lifetime or router lifetime? > > I meant: "If the implementations always set the PIO Valid Lifetime to > the Router Lifetime, as suggested in draft-gont-6man-slaac-renum". > > Right, the thing that concerns me about this is CPEs use all kinds of > interesting values for router lifetime.  I guess it's a smaller value by > definition (9000 seconds). 9000 seconds is actually the longest possible value. The default Router Lifetime is, according to RFC4861, 1800 seconds (30 minutes). The math and recommendation in RFC7772 somehow makes the default value in RFC4841 non-compliant -- I guess one takes that as "rough numbers", and considers 30 minutes to be within the recommendations in RFC7772. That said, the text I had suggested does include a reference to RFC7772. Thoughts? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 6 12:55:59 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8C93A0DEE for ; Mon, 6 Apr 2020 12:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qacafe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfhJRJYeR9OJ for ; Mon, 6 Apr 2020 12:55:54 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AB43A0DF7 for ; Mon, 6 Apr 2020 12:55:43 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id 31so1004768wre.5 for ; Mon, 06 Apr 2020 12:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YGIquCUGX8Usr7+uSGbkkld+QFyr6/dg+4lKvJlsQzs=; b=X+7/TGWGcM4DVWnYUs0fzYfSe979PFSzku81eEqYf8pWsWNkBjPZtgNNs9RnKfLyVu FBv9aknQ/uMTcA9Oi5Hl2yZKr9Dcj0kXLMv8BBv1tlKd6Pk+bQ3QS1qLF7ryK1PqcskH RqJ8wFvbNpP2xlwJ4yxZ/ln54BW5/XYQF3iuw= 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=YGIquCUGX8Usr7+uSGbkkld+QFyr6/dg+4lKvJlsQzs=; b=bx4g+2hx0PqdY2hqaH2Ep0KJOoRE00QeMFNFYXHvbgkrN7/Rzm7xR/9ScR6h/YYxhi bN9wSHkJWyi9e7OteuaabUQxj705D584B50DXUgSQBkRdMQsfHdpcUWfBjayncQQ72YW Ox5xNOiJ42W4AQdiVWi5twGPoZ4gnn74lvHx+cRlFD0/Kj8bpp56KtuYfyR+sH4wHSJ/ 1CRA4MeLw82EoLN006HSCQNIYtmyM0thRA8sbwOi8xO5KxCMSo0wQpXsEsjdTN5D9Aem H80nQPbRUWyYbz+WW1plf0zyRnrg7TUMz7SX8bmmBx8oqzW1wR82589/kFcs4BGYCmxG ZCOg== X-Gm-Message-State: AGi0PubXdnPPNv006U5+K0L91NK00EVJVPIIOFmHw9TWf5vnW+tpUgxX 5W5fMzngIda+ScPQxySaaIUME+83lKUzr3ScvohNNA== X-Google-Smtp-Source: APiQypJeDR5lpMsBklwCMui25Sxl10zhVeuieZdPVezX4ws51d/JWOBJVN3MjR/ia39ooTtzcoOoSjJUvt6KNhoDgdc= X-Received: by 2002:a5d:5688:: with SMTP id f8mr892837wrv.245.1586202942210; Mon, 06 Apr 2020 12:55:42 -0700 (PDT) MIME-Version: 1.0 References: <3b0d9b52-e7c5-45cd-bdfc-b8b8f15218a0@si6networks.com> In-Reply-To: From: Timothy Winters Date: Mon, 6 Apr 2020 15:55:31 -0400 Message-ID: To: Fernando Gont Cc: Lorenzo Colitti , Ron Bonica , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e99a0f05a2a4a6a8" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 19:55:56 -0000 --000000000000e99a0f05a2a4a6a8 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 6, 2020 at 3:45 PM Fernando Gont wrote: > On 6/4/20 16:25, Timothy Winters wrote: > > > > > > On Mon, Apr 6, 2020 at 12:38 PM Fernando Gont > > wrote: > > > > On 6/4/20 12:34, Timothy Winters wrote: > > [...] > > > Could you elaborate? What specifically doesn't apply to RA > > transmission? > > > > > > I'm not aware of any prefix/address lifetimes from DHCPv6 > > affecting RA > > > intervals. > > > > So, what happens if, say, the DHCPv6-PD is, say, two months? The set > > the > > Valid/Prefix Lifetime of PIOs to that value? > > > > Yes at the moment. > > What lifetime do they use for the PIOs say, 15 days after receiving the > one-month lease? Still 30 days? -- that seems very broken. And yet > another way for these problems to appear. > About 70% don't count down so they would say two months in your example. > > > > > > > Note: If CE Routers Advertise the lifetimes as recommended in > > this > > > document, the RAs will change only for the last "Valid > Lifetime" > > > seconds. > > > > > > Or, please let me elaborate in a different way: > > > > > > 1) CE Routers can't just copy the lifetime from DHCPv6-PD, > > because > > > otherwise, the first second after the first RA is sent, they > > would be > > > announcing bogus RAs. > > > Say, if the DHCPv6-PD is one month. If you simply copy the > > lifetime > > > from > > > DHCPv6-PD, then, after 15 days, you'd be advertising a prefix > > that > > > claims a lifetime 15 longer (double time!) than it really is. > > > > > > 2) Now, if, say, an implementation uses a shorter router > > lifetime (say, > > > one hour, or the recommended default of 30 minutes), then > > only the last > > > hour or half hour of the months will the announced PIO > > lifetimes be > > > incorrect. > > > > > > Thoughts? > > > > > > Did you mean valid lifetime or router lifetime? > > > > I meant: "If the implementations always set the PIO Valid Lifetime to > > the Router Lifetime, as suggested in draft-gont-6man-slaac-renum". > > > > Right, the thing that concerns me about this is CPEs use all kinds of > > interesting values for router lifetime. I guess it's a smaller value by > > definition (9000 seconds). > > 9000 seconds is actually the longest possible value. The default Router > Lifetime is, according to RFC4861, 1800 seconds (30 minutes). The math > and recommendation in RFC7772 somehow makes the default value in RFC4841 > non-compliant -- I guess one takes that as "rough numbers", and > considers 30 minutes to be within the recommendations in RFC7772. > > That said, the text I had suggested does include a reference to RFC7772. > > Thoughts? I think this can help, and would recommend going with RFC 7772 which says between 45 to 90 mins. > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --000000000000e99a0f05a2a4a6a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Apr 6, 2020 at 3:45 PM Fernando G= ont <fgont@si= 6networks.com> wrote:
On 6/4/20 16:25, Timothy Winters wrote:
>
>
> On Mon, Apr 6, 2020 at 12:38 PM Fernando Gont <fgont@si6networks.com
> <mailto:= fgont@si6networks.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 6/4/20 12:34, Timothy Winters wrote:
>=C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Could you elaborate? What = specifically doesn't apply to RA
>=C2=A0 =C2=A0 =C2=A0transmission?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I'm not aware of any prefix/address lifet= imes from DHCPv6
>=C2=A0 =C2=A0 =C2=A0affecting RA
>=C2=A0 =C2=A0 =C2=A0 > intervals.
>
>=C2=A0 =C2=A0 =C2=A0So, what happens if, say, the DHCPv6-PD is, say, tw= o months? The set
>=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0Valid/Prefix Lifetime of PIOs to that value?
>
>=C2=A0 =C2=A0Yes at the moment.

What lifetime do they use for the PIOs say, 15 days after receiving the one-month lease? Still 30 days? -- that seems very broken. And yet
another way for these problems to appear.
About 70% do= n't count down so they would say two months in your example.=C2=A0 =C2= =A0=C2=A0




>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Note: If CE Routers Advert= ise the lifetimes as recommended in
>=C2=A0 =C2=A0 =C2=A0this
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0document, the RAs will cha= nge only for the last "Valid Lifetime"
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0seconds.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Or, please let me elaborat= e in a different way:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A01) CE Routers can't ju= st copy the lifetime from DHCPv6-PD,
>=C2=A0 =C2=A0 =C2=A0because
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0otherwise, the first secon= d after the first RA is sent, they
>=C2=A0 =C2=A0 =C2=A0would be
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0announcing bogus RAs.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Say, if the DHCPv6-PD is o= ne month. If you simply copy the
>=C2=A0 =C2=A0 =C2=A0lifetime
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0from
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0DHCPv6-PD, then, after 15 = days, you'd be advertising a prefix
>=C2=A0 =C2=A0 =C2=A0that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0claims a lifetime 15 longe= r (double time!) than it really is.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A02) Now, if, say, an implem= entation uses a shorter router
>=C2=A0 =C2=A0 =C2=A0lifetime (say,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0one hour, or the recommend= ed default of 30 minutes), then
>=C2=A0 =C2=A0 =C2=A0only the last
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0hour or half hour of the m= onths will the announced PIO
>=C2=A0 =C2=A0 =C2=A0lifetimes be
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0incorrect.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Thoughts?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Did you mean valid lifetime or router lifetim= e?
>
>=C2=A0 =C2=A0 =C2=A0I meant: "If the implementations always set th= e PIO Valid Lifetime to
>=C2=A0 =C2=A0 =C2=A0the Router Lifetime, as suggested in draft-gont-6ma= n-slaac-renum".
>
> Right, the thing that concerns me about this is CPEs use all kinds of =
> interesting values for router lifetime.=C2=A0 I guess it's a small= er value by
> definition (9000 seconds).

9000 seconds is actually the longest possible value. The default Router Lifetime is, according to RFC4861, 1800 seconds (30 minutes). The math
and recommendation in RFC7772 somehow makes the default value in RFC4841 non-compliant -- I guess one takes that as "rough numbers", and <= br> considers 30 minutes to be within the recommendations in RFC7772.

That said, the text I had suggested does include a reference to RFC7772.
Thoughts?
=C2=A0I think this can help, and would recommend= going with RFC 7772 which says between 45 to 90 mins.
=C2=A0

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




--000000000000e99a0f05a2a4a6a8-- From nobody Mon Apr 6 13:34:49 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316AE3A0765 for ; Mon, 6 Apr 2020 13:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 4fUWT2T7N09k for ; Mon, 6 Apr 2020 13:34:44 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C603A074B for ; Mon, 6 Apr 2020 13:34:43 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 58CA980781; Mon, 6 Apr 2020 22:34:40 +0200 (CEST) To: Timothy Winters Cc: Lorenzo Colitti , Ron Bonica , "v6ops@ietf.org" References: <3b0d9b52-e7c5-45cd-bdfc-b8b8f15218a0@si6networks.com> From: Fernando Gont Message-ID: <8babb1e6-e7d5-433a-d0d2-f9476d9a8a04@si6networks.com> Date: Mon, 6 Apr 2020 17:15:16 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 20:34:48 -0000 On 6/4/20 16:55, Timothy Winters wrote: [---] > >     So, what happens if, say, the DHCPv6-PD is, say, two months? > The set > >     the > >     Valid/Prefix Lifetime of PIOs to that value? > > > >   Yes at the moment. > > What lifetime do they use for the PIOs say, 15 days after receiving the > one-month lease? Still 30 days? -- that seems very broken. And yet > another way for these problems to appear. > > About 70% don't count down so they would say two months in your example. Your data is *very* valuable. It agrees what I had seen (although I hadn't seen so many CPEs as to be able to produce stats). It is good to keep in mind, and I believe it serves as a good motivator for Section 2.1. [...] > > Right, the thing that concerns me about this is CPEs use all > kinds of > > interesting values for router lifetime.  I guess it's a smaller > value by > > definition (9000 seconds). > > 9000 seconds is actually the longest possible value. The default Router > Lifetime is, according to RFC4861, 1800 seconds (30 minutes). The math > and recommendation in RFC7772 somehow makes the default value in > RFC4841 > non-compliant -- I guess one takes that as "rough numbers", and > considers 30 minutes to be within the recommendations in RFC7772. > > That said, the text I had suggested does include a reference to RFC7772. > > Thoughts? > >  I think this can help, and would recommend going with RFC 7772 which > says between 45 to 90 mins. I'd probably stick with 45' or the RFC4861 default of '30 (which somehow begs the question of how the default spec value can be outside a BCP..). After all, in the light of RFC7772 45' is good enough -- and the increased Router Lifetime also comes at a price. Thoughts? Thanks again! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 6 13:44:54 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D183A0874 for ; Mon, 6 Apr 2020 13:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qacafe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7_L_1kJenDa for ; Mon, 6 Apr 2020 13:44:51 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0813A086A for ; Mon, 6 Apr 2020 13:44:50 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id g3so1194712wrx.2 for ; Mon, 06 Apr 2020 13:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hUH/fQ5cy+lum9411M2N8muxb4G9S9pP08TJB7bxNfo=; b=DtKHhz4gfMy2bKL5BtaUdk8OO/1Py9JD5SYpewJdet71kv9Q+Oi9dvK5sR59XOuGEo q09nPTp6L5RmLckAxVh8lXdljS9/jaN/4xJbpmjAoWY13T0nfKXXLvow88hqp7zh2U68 9oC9ENjNSJqmLU+uq8MSdnUUj92GVjUY4WAqg= 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=hUH/fQ5cy+lum9411M2N8muxb4G9S9pP08TJB7bxNfo=; b=OrEmHpn1yJx/Gar12PU5dR3AqE/TE3/97BjkmZuWySddXyEd9HrByViGMZexdRv+W/ HH0NqgacXI4LTIGtbJ1nZPAC6l3/EYvPDw87rl3LGAjqEZq2STSUtbNNkUogMgsrsjW3 rAlA2fdR3feZeVbjy3BzQZFY0ETmGkNP1IFwCb35XjcDfuBwADoiP42WRA9Csq6yh1LN +y6JBKyo6qAwwC59UdgINeiAwb9WCBVpUwpnGaMmhMTWvsT+lQGsmbsQ1CXJr7qPlQ3b bTYVv9JJ2XFnis5WALD3hqFLLlt30Fa4GjJTubDPkQpm17NmHPoKgKi7ww9ARa4H+GeL uYoQ== X-Gm-Message-State: AGi0Pubqr73zlgzoUynotTqm/cvaDrTsd2HoFZUSBJYtBd4WOQkZNuJ4 vP0TydvPPJ3eUzO9JAe7uVB4fRFBzZf3kj5ze7X4ww== X-Google-Smtp-Source: APiQypLyPsguqdTiZep/4ev+GlgFC1UQYZ5VVhSTTOZG7c77r6x5bigrnr+0FSPYKndQxa7+fSmm+fPVIcb1FnQxX7c= X-Received: by 2002:adf:fe87:: with SMTP id l7mr1037782wrr.377.1586205889527; Mon, 06 Apr 2020 13:44:49 -0700 (PDT) MIME-Version: 1.0 References: <3b0d9b52-e7c5-45cd-bdfc-b8b8f15218a0@si6networks.com> <8babb1e6-e7d5-433a-d0d2-f9476d9a8a04@si6networks.com> In-Reply-To: <8babb1e6-e7d5-433a-d0d2-f9476d9a8a04@si6networks.com> From: Timothy Winters Date: Mon, 6 Apr 2020 16:44:38 -0400 Message-ID: To: Fernando Gont Cc: Lorenzo Colitti , Ron Bonica , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000961c7b05a2a5567a" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 20:44:53 -0000 --000000000000961c7b05a2a5567a Content-Type: text/plain; charset="UTF-8" On Mon, Apr 6, 2020 at 4:34 PM Fernando Gont wrote: > On 6/4/20 16:55, Timothy Winters wrote: > [---] > > > So, what happens if, say, the DHCPv6-PD is, say, two months? > > The set > > > the > > > Valid/Prefix Lifetime of PIOs to that value? > > > > > > Yes at the moment. > > > > What lifetime do they use for the PIOs say, 15 days after receiving > the > > one-month lease? Still 30 days? -- that seems very broken. And yet > > another way for these problems to appear. > > > > About 70% don't count down so they would say two months in your example. > > Your data is *very* valuable. It agrees what I had seen (although I > hadn't seen so many CPEs as to be able to produce stats). It is good to > keep in mind, and I believe it serves as a good motivator for Section 2.1. > > > [...] > > > Right, the thing that concerns me about this is CPEs use all > > kinds of > > > interesting values for router lifetime. I guess it's a smaller > > value by > > > definition (9000 seconds). > > > > 9000 seconds is actually the longest possible value. The default > Router > > Lifetime is, according to RFC4861, 1800 seconds (30 minutes). The > math > > and recommendation in RFC7772 somehow makes the default value in > > RFC4841 > > non-compliant -- I guess one takes that as "rough numbers", and > > considers 30 minutes to be within the recommendations in RFC7772. > > > > That said, the text I had suggested does include a reference to > RFC7772. > > > > Thoughts? > > > > I think this can help, and would recommend going with RFC 7772 which > > says between 45 to 90 mins. > > I'd probably stick with 45' or the RFC4861 default of '30 (which somehow > begs the question of how the default spec value can be outside a BCP..). > After all, in the light of RFC7772 45' is good enough -- and the > increased Router Lifetime also comes at a price. Works for me. > > Thoughts? > > Thanks again! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --000000000000961c7b05a2a5567a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 6, 2020 at 4:34 PM Fernan= do Gont <fgont@si6networks.com<= /a>> wrote:
O= n 6/4/20 16:55, Timothy Winters wrote:
[---]
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0So, what happens if, say, = the DHCPv6-PD is, say, two months?
>=C2=A0 =C2=A0 =C2=A0The set
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Valid/Prefix Lifetime of P= IOs to that value?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0Yes at the moment.
>
>=C2=A0 =C2=A0 =C2=A0What lifetime do they use for the PIOs say, 15 days= after receiving the
>=C2=A0 =C2=A0 =C2=A0one-month lease? Still 30 days? -- that seems very = broken. And yet
>=C2=A0 =C2=A0 =C2=A0another way for these problems to appear.
>
> About 70% don't count down so they would say two months in your ex= ample.

Your data is *very* valuable. It agrees what I had seen (although I
hadn't seen so many CPEs as to be able to produce stats). It is good to=
keep in mind, and I believe it serves as a good motivator for Section 2.1.<= br>

[...]
>=C2=A0 =C2=A0 =C2=A0 > Right, the thing that concerns me about this = is CPEs use all
>=C2=A0 =C2=A0 =C2=A0kinds of
>=C2=A0 =C2=A0 =C2=A0 > interesting values for router lifetime.=C2=A0= I guess it's a smaller
>=C2=A0 =C2=A0 =C2=A0value by
>=C2=A0 =C2=A0 =C2=A0 > definition (9000 seconds).
>
>=C2=A0 =C2=A0 =C2=A09000 seconds is actually the longest possible value= . The default Router
>=C2=A0 =C2=A0 =C2=A0Lifetime is, according to RFC4861, 1800 seconds (30= minutes). The math
>=C2=A0 =C2=A0 =C2=A0and recommendation in RFC7772 somehow makes the def= ault value in
>=C2=A0 =C2=A0 =C2=A0RFC4841
>=C2=A0 =C2=A0 =C2=A0non-compliant -- I guess one takes that as "ro= ugh numbers", and
>=C2=A0 =C2=A0 =C2=A0considers 30 minutes to be within the recommendatio= ns in RFC7772.
>
>=C2=A0 =C2=A0 =C2=A0That said, the text I had suggested does include a = reference to RFC7772.
>
>=C2=A0 =C2=A0 =C2=A0Thoughts?
>
>=C2=A0 =C2=A0I think this can help, and would recommend going with RFC = 7772 which
> says between 45 to 90 mins.

I'd probably stick with 45' or the RFC4861 default of '30 (whic= h somehow
begs the question of how the default spec value can be outside a BCP..). After all, in the light of RFC7772 45' is good enough -- and the
increased Router Lifetime also comes at a price.
=C2=A0

Thoughts?

Thanks again!

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




--000000000000961c7b05a2a5567a-- From nobody Mon Apr 6 13:46:42 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AB73A0A11 for ; Mon, 6 Apr 2020 13:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 l0LG9vVW6dxw for ; Mon, 6 Apr 2020 13:46:35 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9061A3A08E0 for ; Mon, 6 Apr 2020 13:46:35 -0700 (PDT) Received: from [IPv6:2001:470::2cb:1042:b6ea:334c:47f0] ([IPv6:2001:470:0:2cb:1042:b6ea:334c:47f0]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 036KkWQZ840018 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Apr 2020 13:46:33 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 036KkWQZ840018 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586205993; bh=Za79I3U1S//lL+UydalKl8Fb3LIn4bWxMcdDOgMzhJo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=eYKuB/CvVpaY6EI/pNC3Nk+oayF4t/ESzCmXZCn9zhrgCqnhf2iL3GCyVuvBiQts0 EYglBUMPctxK/jKGezHRlargejb9/Abuw4+qdO1is9MjpCrA0QdUo3mfwkQl0887/f KBGz33KRy6+/pHq1V+DiFMrW8n3Z5QvMxYFkEjy8= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Owen DeLong In-Reply-To: <8babb1e6-e7d5-433a-d0d2-f9476d9a8a04@si6networks.com> Date: Mon, 6 Apr 2020 13:46:31 -0700 Cc: Timothy Winters , Ron Bonica , "v6ops@ietf.org" , Lorenzo Colitti Content-Transfer-Encoding: quoted-printable Message-Id: <22363FDA-8FB0-48B0-B70B-68B17D0951F1@delong.com> References: <3b0d9b52-e7c5-45cd-bdfc-b8b8f15218a0@si6networks.com> <8babb1e6-e7d5-433a-d0d2-f9476d9a8a04@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Mon, 06 Apr 2020 13:46:33 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 20:46:41 -0000 > On Apr 6, 2020, at 1:15 PM, Fernando Gont = wrote: >=20 > On 6/4/20 16:55, Timothy Winters wrote: > [---] >> > So, what happens if, say, the DHCPv6-PD is, say, two = months? >> The set >> > the >> > Valid/Prefix Lifetime of PIOs to that value? >> > >> > Yes at the moment. >> What lifetime do they use for the PIOs say, 15 days after = receiving the >> one-month lease? Still 30 days? -- that seems very broken. And yet >> another way for these problems to appear. >> About 70% don't count down so they would say two months in your = example. >=20 > Your data is *very* valuable. It agrees what I had seen (although I = hadn't seen so many CPEs as to be able to produce stats). It is good to = keep in mind, and I believe it serves as a good motivator for Section = 2.1. >=20 >=20 > [=E2=80=A6] In theory, a DHCP Server or a Router which is advertising SLAAC PIOs = from a DHCP IA_PD should not advertise a valid lifetime in excess of the = remaining valid time on the lease. In practice, there are likely many sloppy CPE implementations which = simply copy the value from the original IA_PD lifetime specifications = and advertise that until they can=E2=80=99t. As such, the =E2=80=9Csafe=E2= =80=9D thing is definitely to continue supporting the prefix for = 2xMAX_VALID_LIFETIME after it has been removed from leases or PIOs. Owen From nobody Mon Apr 6 14:15:38 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B133A0B62 for ; Mon, 6 Apr 2020 14:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=O3ukjbur; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xdBD7vir Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqEAoKHfytfn for ; Mon, 6 Apr 2020 14:15:35 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45223A0B5C for ; Mon, 6 Apr 2020 14:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4538; q=dns/txt; s=iport; t=1586207735; x=1587417335; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hQoa1hb80JJgi19PrE2Jl6CTBZpR8bTpflqKC+AYBh4=; b=O3ukjburkQ/qMa0sv4dnzLDiLCRB4UM5LabxViO3zSKQN0O8GNEx5JAW 172idpj1qv70U8cQ1BbNMjhScgdf8j32vrRZUhksVj1D+B9Ll6mqInNjf BYTtkK7sVt3imapJrT0mHUTiMgGIxrOtq2XzUF7RMX478yE3clZGG81li Q=; IronPort-PHdr: =?us-ascii?q?9a23=3A4XxoGRyVi/OV4D7XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YRGN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A+GsHbIQKUh?= =?us-ascii?q?YEjcsMmAl1HsmBG2XwLeXhaGoxG8ERHFI=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaBQDCmote/5hdJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVFAFgUQgBAsqCoQRg0UDimaCX5geglIDVAoBAQEMAQEtAgQ?= =?us-ascii?q?BAYREAheCMiQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFcQEBAQIBEhERDAEBNwE?= =?us-ascii?q?PAgEIDgwCJgICAjAVEAIEAQ0FIoMEgkwDDiABpjUCgTmIYnWBMoJ/AQEFgkW?= =?us-ascii?q?CehiCDQmBDiqMMxqCAIERJxyCTT6ENgIWgxIygiyNaReDBIhqljp6CoI9jU2?= =?us-ascii?q?JXR2CTo0VjB+LQIN3nCUCBAIEBQIOAQEFgWkigVdwFTsqAYI+UBgNjh0MF4N?= =?us-ascii?q?QilV0gSmLY4EyATBfAQE?= X-IronPort-AV: E=Sophos;i="5.72,352,1580774400"; d="scan'208";a="459198405" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Apr 2020 21:15:35 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 036LFYiu001476 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Apr 2020 21:15:34 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 16:15:34 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 17:15:33 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 6 Apr 2020 17:15:33 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oTUeGvkoA/kaamekKSGaNRaoIjqZdLjBJvLgyanbB+SUgOYBAuYxyfncx5UTqRIADgUEP1CQZqaZ+UNmDhY/JrE5IP65QO13rJIkaBTRoG89G17/E9gznqT/28pt423BmEdTbfT1r4O6L5Nj572naPfRdt8hyjHr4eZLylVIuB+kxp4bhNTKebBZq39WlseXrq/hO2ZBLEDR8fQlvbQJsCnX3HkCmSw/EVAHqRxyxS/5ZoG2P/aYJEGrL+yt1T8OZqkYhyxog8TqWWM/cMmHpVTcgyIMGitXlZrjJiK3QitXor9DZ6oJlNzJqBwr+k5TGcE2sBFD19K7+CtIpe/0aQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hQoa1hb80JJgi19PrE2Jl6CTBZpR8bTpflqKC+AYBh4=; b=gVOAWk1ZHf1QoE/jc7DlcgZC8CBnRzkvsoWOfRr3TzGjtxPLgD8hmyYZgpn7HVffd2GthN3UIDKRDROtKN8LP8cyy+/vBjtWssV+FlXcDVL7pbfRCcC39lLMLw3m5BrrJy/+mjn17QUFLAwgCfbHPfUY0e5Gl0noPQxJqZGv4TBL7dpYhK7ww4Zm6rJxJLYyxQLPQVQ9H822ZdK2jvmopR/L9alTQwfNyV8TKWxf4cOpYsanJP5qIamuGGdvJuHj/z6bi8lglIFzzBT+uAG1EiDaSx0jG5gIHg1HMUMeRIif+MOMYQREextvRfTulG5YvDACmrM3NXegO7Tc5JRmug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hQoa1hb80JJgi19PrE2Jl6CTBZpR8bTpflqKC+AYBh4=; b=xdBD7virte441fbZcuzC2EuDrLrfz0iBrUR269u/8a571Vub02zvEAvvS0/NsbqBQJ8pBj5SLcLvn70WjJ65Cer15QhOgHof7KL58nTuFcUvb0pmBuQYnI+OefwvCSAE5MI81AS+r0cd4cdZS0PuyPWweycjoRBT/4K+PHBeeTA= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2610.namprd11.prod.outlook.com (2603:10b6:406:ab::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Mon, 6 Apr 2020 21:15:32 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 21:15:32 +0000 From: "Bernie Volz (volz)" To: Fernando Gont , "otroan@employees.org" CC: Ron Bonica , "v6ops@ietf.org" Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdYGqnrRGOoD4f0yRz2uh9FnYboxrQFaGSGAAAIsGEAAAKuIAAAAIs2gAAOzCYAAAdK0gAAAhmmA Date: Mon, 6 Apr 2020 21:15:32 +0000 Message-ID: References: <52688D39-5537-44BA-B1C8-4341C21D1B02@employees.org> <6186B94B-2504-48C7-8A20-AEB5896D1BB1@employees.org> <56667bf5-97ac-5427-6d75-7ff4f32bf946@si6networks.com> In-Reply-To: <56667bf5-97ac-5427-6d75-7ff4f32bf946@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f7cd01a-07bc-4ea1-a094-08d7da6fa42b x-ms-traffictypediagnostic: BN7PR11MB2610: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(376002)(366004)(39850400004)(346002)(396003)(53546011)(8936002)(6506007)(2906002)(66446008)(64756008)(66556008)(26005)(81156014)(36756003)(186003)(76116006)(66476007)(316002)(66946007)(2616005)(81166006)(4326008)(33656002)(6486002)(110136005)(6512007)(54906003)(66574012)(86362001)(71200400001)(478600001)(91956017)(8676002)(5660300002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mO2L5paY4UaQ0CJOc5K2ySmiDjDvjdUrLGSjD3YPwn2WBWWRCanR4RD7KPc5GKUIFKrZEmHfl3vp7NqoAmA9n1JE5rOILf+t1yjIK88syOUQ7EiKGmbMo0gm4e5ysDtp9nCvNfW8ZpFmptWFtqGebX3Kcit0tHqfLse3HdNP6Y1MN/IzO3JgDQ0RrmbJ+B2OcnFhQLZbSy7F3y3hXQVHzGQQpGFRt6a0uewJMTblrnPtU7XRw642ga/mnr0hVZ3R9fUt8cB1k15O9V5KwYpygHQJWF6yU45T/0hvU8WkP143NwmhrCufRjHzBO4L3+XbvDq+ExBJu4RPKAz4VNNfLm7+fwnC+X0X5fmjEavNmSByzfgXjPeS0FSyZww7KelydWilUXcaMsH2rmyNh+ok/CpKuWl8CCninVV6amNqE5Qu7CrBRE9JJAoxP2c6AKl5 x-ms-exchange-antispam-messagedata: Y113MAmYo/JkWClBBXY2TkVqnxebN4Ek6NGiJP2feGkmgHOW5ZnTuzpGfvdY8HTUw1ZuYZZuxYQffYYOwySztjlQMHvJqnv32N0CYWRAWVNLDxP67MRKbuQrLrfX2FDFKpNwkVNxQ/KaIV43P6C4sA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7618223CB1CF4E44B28C959EAA21F12E@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2f7cd01a-07bc-4ea1-a094-08d7da6fa42b X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 21:15:32.4893 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DV/28pydT/rIVZe9QNsTZ+GAnezmwS8xo/Y65I8tdz/s72gGS3nv3xB4hem6PKCR X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2610 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 21:15:38 -0000 SGkgLSBpbmxpbmUgKEJWPikuDQoNCi0gQmVybmllDQoNCu+7v09uIDQvNi8yMCwgMToxOCBQTSwg IkZlcm5hbmRvIEdvbnQiIDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+IHdyb3RlOg0KDQogICAgSGks IE9sZSwNCiAgICANCiAgICBPbiA2LzQvMjAgMTM6MDgsIG90cm9hbkBlbXBsb3llZXMub3JnIHdy b3RlOg0KICAgIFsuLi5dDQogICAgPj4gWWVzLCB3aGVuIHRoZSBvbGQgUEQgaXMgc3dpdGNoZWQg dG8gYSBuZXcgUEQsIHRoZSBzZXJ2ZXIgd291bGQgYmUgZXhwZWN0ZWQgdG8gc2VuZCB0aGUgb2xk IFBEIHdpdGggMCBsaWZldGltZXMuIEJ1dCBob3cgbG9uZyB3aWxsIHRoZSBzZXJ2ZXIgcmVtZW1i ZXIgdGhpcyBpcyB0aGUga2V5IHF1ZXN0aW9uIGFuZCwgZm9yIGV4YW1wbGUgaWYgMzAgZGF5cyB3 ZXJlIHJlbWFpbmluZyBvbiB0aGUgb2xkIFBELCBpdCBzaG91bGQga2VlcCBzZW5kaW5nIGl0IGZv ciAzMCBkYXlzLg0KICAgID4gDQogICAgPiBJIGRvbid0IHRoaW5rIHRoYXQgbmVjZXNzYXJpbHkg Zm9sbG93cy4NCiAgICA+IFRoZSBkZWxlZ2F0aW5nIHNlcnZlciBpcyBhbGxvd2VkIHRvIGNoYW5n ZSB0aGUgbGlmZXRpbWVzIG9mIHRoZSBvbGQgcHJlZml4LCBzbyBJIHdvdWxkIGltYWdpbmUgaXQg d2FzIG9ubHkgbmVjZXNzYXJ5IHRvIGluY2x1ZGUgdGhlIG9sZCBwcmVmaXggaW4gb25lIERIQ1Ag ZXhjaGFuZ2UuDQogICAgDQogICAgU2luY2UgdGhlIERIQ1B2Ni1QRCBjbGllbnQgY291bGQgY29t ZSBiYWNrIGFueXRpbWUgd2l0aGluZyB0aGUgREhDUHY2LVBEIA0KICAgIGxlYXNlIHRpbWUgb2Yg dGhlIHN0YWxlIHByZWZpeCwgdGhlIERIQ1B2NiBzZXJ2ZXIgd291bGQgbmVlZCB0byByZW1lbWJl ciANCiAgICB0aGlzIGZvciBzdWNoIHBlcmlvZCBvZiB0aW1lLiBJIGFzc3VtZSB0aGF0J3Mgd2hh dCBCZXJuaWUgbWVhbnQuDQogIA0KQlY+IENvcnJlY3QuIFRoZSBzZXJ2ZXIgd291bGQgYmUgb2Js aWdhdGVkIHRvIHJldGFpbiBpdCB1bnRpbCB0aGUgKGxvbmdlc3QpIHZhbGlkIGxpZmV0aW1lIGl0 IGhhZCBzZW50IHRoZSBjbGllbnQgZXhwaXJlZC4gVGhlIHF1ZXN0aW9uIGlzIGhvdyB0aGUgc2Vy dmVyIGtub3dzIHdoZW4gYSBESENQIGV4Y2hhbmdlIGlzIGNvbXBsZXRlIChqdXN0IGJlY2F1c2Ug aXQgc2VudCBhIFJlcGx5IGlzIG5vdCBhIGd1YXJhbnRlZSB0aGUgY2xpZW50IHJlY2VpdmVkIGl0 KS4gQW5kLCBpZiBpdCBkb2VzIHVzZSB0aGF0IHRoZW4gdGhlIGlzc3VlIGlzIHRoYXQgdGhpcyBk b2Vzbid0IGhlbHAgdGhlIENQRSBpZiBpdCByZWJvb3RlZCBhZnRlciB0aGlzIChvciBldmVuKSBz ZXZlcmFsIGV4Y2hhbmdlcyBhcyB0aGVyZSBjb3VsZCBzdGlsbCBiZSBjbGllbnRzIGJlaGluZCB0 aGUgQ1BFIHRoYXQgaGF2ZSBub3QgcmVjZWl2ZWQgYW4gdXBkYXRlZCBSQSB3aXRoIHRoZSBkZXBy ZWNhdGVkIHByZWZpeC4NCg0KICAgID4+IElmIHlvdSByZWFkIHRoZSB0ZXh0IG9mIHRoZSBwcm9w b3NlZCBkcmFmdCwgaXQgb25seSBwdXRzIGEgcmVxdWlyZW1lbnQgb24gdGhlIENQRToNCiAgICA+ Pg0KICAgID4+IDIuMi4gIFNpZ25hbGluZyBTdGFsZSBDb25maWd1cmF0aW9uIEluZm9ybWF0aW9u DQogICAgPj4NCiAgICA+PiAgICBJbiBvcmRlciB0byBwaGFzZS1vdXQgc3RhbGUgY29uZmlndXJh dGlvbiBpbmZvcm1hdGlvbjoNCiAgICA+Pg0KICAgID4+ICAgIG8gIEEgQ0Ugcm91dGVyIHNlbmRp bmcgUkFzIHRoYXQgYWR2ZXJ0aXNlIGR5bmFtaWNhbGx5LWxlYXJuZWQNCiAgICA+PiAgICAgICBw cmVmaXhlcyAoZS5nLiB2aWEgREhDUHY2LVBEKSBvbiBhbiBpbnRlcmZhY2UgTVVTVCByZWNvcmQs IG9uDQogICAgPj4gICAgICAgc3RhYmxlIHN0b3JhZ2UsIHRoZSBsaXN0IG9mIHByZWZpeGVzIGJl aW5nIGFkdmVydGlzZWQgb24gZWFjaA0KICAgID4+ICAgICAgIG5ldHdvcmsgc2VnbWVudCwgYW5k IHRoZSAiQSIgYW5kICJMIiBmbGFncyBvZiB0aGUgY29ycmVzcG9uZGluZw0KICAgID4+ICAgICAg IFBJT3MuDQogICAgPiANCiAgICA+IFllcywgYW5kIGFzIEkgc2FpZCB0aGF0J3MgYSBiYW5kLWFp ZCBmb3IgYSBicm9rZW4gZGVwbG95bWVudC4NCiAgICA+IEFuZCBzdWdnZXN0ZWQgdGhhdCBhIHBh cmFncmFwaCBleHBsYWluaW5nIHRoZSBjb3JyZWN0IHJlbnVtYmVyaW5nIHByb2NlZHVyZSB3YXMg YWRkZWQuIFRvIGF2b2lkIGNvbmZ1c2lvbi4NCiAgICA+IE5vdCBhbGwgQ1BFcyBhcmUgZXZlciBn b2luZyB0byBkbyB0aGlzIGFueXdheS4NCiAgICANCiAgICBIb3cgYWJvdXQgYWRkaW5nIHRoaXM6 DQogICAgICAgIElQdjYgbmV0d29yayByZW51bWJlcmluZyBpcyBleHBlY3RlZCB0byB0YWtlIHBs YWNlIGluIGEgcGxhbm5lZA0KICAgICAgICBtYW5uZXIsIHdpdGggb2xkL3N0YWxlIHByZWZpeGVz IGJlaW5nIHBoYXNlZC1vdXQgdmlhIHJlZHVjZWQgcHJlZml4DQogICAgICAgIGxpZmV0aW1lcyB3 aGlsZSBuZXcgcHJlZml4ZXMgKHdpdGggbm9ybWFsIGxpZmV0aW1lcykgYXJlIGludHJvZHVjZWQu DQogICAgICAgIEhvd2V2ZXIsIHRoZXJlIGFyZSBhIG51bWJlciBvZiBzY2VuYXJpb3MgdGhhdCBt YXkgbGVhZCB0byB0aGUgc28tDQogICAgICAgIGNhbGxlZCAiZmxhc2gtcmVudW1iZXJpbmciIGV2 ZW50cywgd2hlcmUgdGhlIHByZWZpeCBiZWluZyBlbXBsb3llZCBvbg0KICAgICAgICBhIG5ldHdv cmsgc3VkZGVubHkgYmVjb21lcyBpbnZhbGlkIGFuZCByZXBsYWNlZCBieSBhIG5ldyBwcmVmaXgN CiAgICAgICAgW0ktRC5pZXRmLXY2b3BzLXNsYWFjLXJlbnVtXS4gT25lIG9mIHN1Y2ggc2NlbmFy aW9zIGlzIHRoYXQgaW4gd2hpY2gNCiAgICAgICAgYSBESENQdjYtc2VydmVyIGVtcGxveXMgZHlu YW1pYyBwcmVmaXhlcywgYW5kIHRoZSBDdXN0b21lciBFZGdlDQogICAgICAgIFJvdXRlciBjcmFz aGVzIGFuZCByZWJvb3RzLiBUaGUgcmVxdWlyZW1lbnQgaW4gdGhpcyBzZWN0aW9uIGlzIG1lYW50 DQogICAgICAgIHRvIGFsbG93IEN1c3RvbWVyIEVkZ2UgUm91dGVycyB0byBkZXByZWNhdGUgc3Rh bGUgaW5mb3JtYXRpb24gaW4gc3VjaA0KICAgICAgICBzY2VuYXJpb3MuDQogICAgDQogICAgdG8g dGhlIFJBVElPTkFMRSBpbiBTZWN0aW9uIDIuMj8NCiAgICANCiAgICBUaGFua3MsDQogICAgLS0g DQogICAgRmVybmFuZG8gR29udA0KICAgIFNJNiBOZXR3b3Jrcw0KICAgIGUtbWFpbDogZmdvbnRA c2k2bmV0d29ya3MuY29tDQogICAgUEdQIEZpbmdlcnByaW50OiA2NjY2IDMxQzYgRDQ4NCA2M0Iy IDhGQjEgRTNDNCBBRTI1IDBENTUgMUQ0RSA3NDkyDQogICAgDQogICAgDQogICAgDQogICAgDQog ICAgDQoNCg== From nobody Mon Apr 6 14:17:30 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4BC3A0B66 for ; Mon, 6 Apr 2020 14:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 884uO5SIHvB4 for ; Mon, 6 Apr 2020 14:17:23 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A245D3A0B64 for ; Mon, 6 Apr 2020 14:17:23 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jLZ7K-0000KBC; Mon, 6 Apr 2020 23:17:14 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> In-reply-to: Your message of "Mon, 6 Apr 2020 18:00:41 +0200 ." <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> Date: Mon, 06 Apr 2020 23:17:13 +0200 Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 21:17:29 -0000 >> That said, setting, the PIO lifetimes in a way that would span past >the DHCPV6-PD would be incorrect. > >Yes, that would violate a fundamental premise of prefix delegation. I disagree. In case of a static prefix it should be possible for the user of the router to set long lifetimes. From nobody Mon Apr 6 14:33:05 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42D83A0C07 for ; Mon, 6 Apr 2020 14:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF4pulY4eMKd for ; Mon, 6 Apr 2020 14:33:02 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1F65A3A0C06 for ; Mon, 6 Apr 2020 14:33:01 -0700 (PDT) Received: from [IPv6:2001:470::2cb:d9ba:37a4:ba62:9c7] ([IPv6:2001:470:0:2cb:d9ba:37a4:ba62:9c7]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 036LWu4E856601 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Apr 2020 14:32:56 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 036LWu4E856601 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586208777; bh=txxDJ0f4t9v+2tx+auASVtaHRAVa/0vfEj+bpmON3P0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=1bNcNS/Yb/7QPogErWisj2LqcQ1KZbrCQctdLc4wxJEegnKpUkoPJTkQDYx2ZAsUS heBhXN+Hc9zm002EI66t7CFcgi+4g/sdntMMmzX/hdRKLz7rzaRr+iYASafTpjzJ9K 0h3GFgUAYGkcQ354yEVEn8u+fDDN/xayohiAHRWg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Owen DeLong In-Reply-To: <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> Date: Mon, 6 Apr 2020 14:32:55 -0700 Cc: Fernando Gont , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5A7E89D4-B4DF-459C-B7CD-38EDAC3AB03D@delong.com> References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> To: otroan@employees.org X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Mon, 06 Apr 2020 14:32:57 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 21:33:04 -0000 > On Apr 6, 2020, at 9:00 AM, otroan@employees.org wrote: >=20 >>>>> 1) Section 2.1. (Interface Between DHCPv6-PD and SLAAC) >>>>>=20 >>>>> It would be nice have a text like >>>>> 'The router MAY provide an option where the user can override = the valid >>>> and >>>>> preferred lifetimes.' >>>>>=20 >>>>> Case in point, my ISP gives me a more or less fixed IPv6 = prefix. However >>>> , >>>>> for technical reasons customers have to run DHCPv6-PD. So this = leave the >>>>> user with no way to manually configre the lifetimes. >>>>=20 >>>> You mean the router simply copies the lifetimes from dhcpve-pd? >>> Supposed that the ISP sets the lifetime of a prefix to one hour and = I want >>> the valid time to be a couple of hours. Then the current text says = that >>> the router has to limit the valid lifetime to what remains of one = hour. >>> I think there should be a way for operator (user of the CPE) to = override this. >>=20 >> I don't mind a CE Router to have knobs for folks to play with (in = fact, that's normally useful). >>=20 >> That said, setting, the PIO lifetimes in a way that would span past = the DHCPV6-PD would be incorrect. >=20 > Yes, that would violate a fundamental premise of prefix delegation. How far do you think we will get if we depend on the intelligence and = diligent disciplined implementation of CPE firmware/software? Yes, it=E2=80=99s wrong, but I guarantee you it probably does happen in = the real world and certainly WILL happen in the real world that PIO = lifetimes will be copied from IA_PDs without regard for the amount of = time since the lease was issued. It=E2=80=99s a stupid mistake, but I bet it becomes a common one as we = strive for ever-cheaper devices. Owen From nobody Mon Apr 6 14:46:58 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AF83A0CE8 for ; Mon, 6 Apr 2020 14:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 6kUnDnTqyrqE for ; Mon, 6 Apr 2020 14:46:45 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C2BA63A0CE4 for ; Mon, 6 Apr 2020 14:46:45 -0700 (PDT) Received: from [IPv6:2001:470::2cb:5cb5:4523:4872:51fd] ([IPv6:2001:470:0:2cb:5cb5:4523:4872:51fd]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 036LkKFY861531 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Apr 2020 14:46:21 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 036LkKFY861531 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586209583; bh=jd3ivrMWkeFVeleKdCbmcGiVJpBjPWrAO2wjencfi+8=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=K0uEPlI0rx+FnsqH/bK1nCOdm6uPEJ+kgYvzunRqwJm/YrGPKwWmgTmT41RfZQZYv wRrdgk7T2V7lO/eHI9LtZJNOFGBuZTXdhHX4wUuQtYnkMhqtRqulHmvrEJZAtuK3Rc vZ0yJITonQRMkfW8DjZMTbUDDNL0RFNtw8BEKVS8= From: Owen DeLong Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4DC4C22B-F9EF-45F2-A701-51403197DA5B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 6 Apr 2020 14:46:19 -0700 In-Reply-To: Cc: Ron Bonica , Timothy Winters , "v6ops@ietf.org" To: Lorenzo Colitti References: X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Mon, 06 Apr 2020 14:46:23 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 21:46:56 -0000 --Apple-Mail=_4DC4C22B-F9EF-45F2-A701-51403197DA5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 6, 2020, at 6:19 AM, Lorenzo Colitti = wrote: >=20 > Based on a fair amount of experience with this sort of thing, this = recommendation is risky: >=20 > * The lifetime values advertised for prefixes corresponding to = a > prefix leased via DHCPv6-PD should be dynamically updated > (rather than static values), since otherwise the advertised > lifetimes would eventually span past the DHCPv6-PD lease = time.. >=20 > The reason is that there are many routers in the field that send RAs = much too often. There are many devices that send RAs at the maximum = permitted rate of one every three seconds (ironically, I think the = reason for this is to prevent the very "client loses connectivity" = roblem this draft is trying to solve). On a phone or smaller device, = processing packets every 3 seconds will destroy battery life. But = because phone manufacturers could not fix routers in the field, they = reacted to this in different ways. > Drop all packets / all multicast packets / all RA packets when the = "device is not in use" (e.g., screen is off). Maybe send an RS when the = screen turns on again. Broken, as you say, but not really impacted by this proposal. > Drop RAs that are received too soon after an identical RA. > Drop RAs that are received too soon after a similar RA (e.g., same RA = but with different lifetime values). > #1 basically breaks IPv6 almost completely, because RAs will time out = and expire. Even if the device sends an RS again when the screen turns = on, connectivity might have been broken while the screen was off, = because the device might have dropped one or more RAs with a critical = update. Devices do need connectivity while the screen is off - for = example, to receive incoming calls and chat messages. #3 works but not = all manufacturers implement it. Android does this by providing the = source code of a bytecode interpreter to chipset vendors and downloading = bytecode to the interpreter based on previously-received RAs, but some = chipset vendors don't support this. I don't think iOS supports this = either. Many devices do #2. It sort of works as long as the RAs are = identical. This is pretty common because it's easy to do in wifi = firmware and pretty much all wifi chipsets support fixed-function = filtering. Sure=E2=80=A6 > By recommending that lifetimes should be dynamically updated, this = draft will defeat devices that do #2. Based on past experience, a likely = outcome is that manufacturers will react by switching to #1 and dropping = all RAs. We should try to avoid making this problem worse with this = draft. But if you don=E2=80=99t update the lifetimes, then you=E2=80=99re = handing out PIOs that contain a lifetime beyond the end of the IA_PD = lease. Could we perhaps recommend sending out PIOs that are 1/4 or 1/3 of the = original IA_PD lease so long as the lease is renewed and then = dynamically counting down to 0 such that the PIO never contains a = lifetime longer than the IA_PD validity? This should provide a best of both worlds=E2=80=A6 Until the IA_PD = expires without renewal, the PIO should contain a fixed lifetime, but in = the (rare) case where a prefix is expiring, we sacrifice some battery = life to avoid a loss of connectivity. Alternatively, perhaps stop issuing PIOs for an IA_PD which has invaded = that last fraction of its lifetime? > The safest way to do so would be to remove this text. A bit less safe = would be to say that the device must cease to send RAs if the RA = lifetime is below the DHCPv6 PD lifetime. A bit less safe would be to = say here that the device MUST respect RFC 7772 and only send RAs once = every few minutes. (The reason that this isn't super safe is that in a = simple router that just glues together dhcpcd and dnsmasq/radvd, it's = not easy to implement. The DHCPv6 client and the RA daemon are two = separate pieces of software written by different authors, so = transferring the DHCPv6 lifetime to the RA lifetime requires getting the = two to collaborate.) +Timothy Winters any = other suggestions? I=E2=80=99m all for sending RAs less frequently. I=E2=80=99m not in favor of RA lifetimes exceeding the DHCPv6 PD = lifetime as you advocate at the beginning of this paragraph. That seems = absurd. Owen --Apple-Mail=_4DC4C22B-F9EF-45F2-A701-51403197DA5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 6, 2020, at 6:19 AM, Lorenzo Colitti <lorenzo=3D40google.com@dmarc.ietf.org> wrote:

Based on a fair amount of experience with = this sort of thing, this recommendation is risky:

      * =  The lifetime values advertised for prefixes corresponding to a
         prefix leased via DHCPv6-PD = should be dynamically updated
        =  (rather than static values), since otherwise the advertised
         lifetimes would eventually = span past the DHCPv6-PD lease time..

The reason is that there = are many routers in the field that send RAs much too often. There are = many devices that send RAs at the maximum permitted rate of one every = three seconds (ironically, I think the reason for this is to prevent = the very "client loses connectivity" roblem this draft is trying to = solve). On a phone or smaller device, processing packets every 3 seconds = will destroy battery life. But because phone manufacturers could = not fix routers in the field, they reacted to this in different = ways.
  1. Drop all = packets / all multicast packets / all RA packets when the "device is not = in use" (e.g., screen is off). Maybe send an RS when the screen turns on = again.

Broken, as you say, but not really impacted by this = proposal.
  1. Drop RAs that are received too soon after an = identical RA.
  1. Drop RAs that are = received too soon after a similar RA (e.g., same RA but with different = lifetime values).
#1 basically breaks IPv6 = almost completely, because RAs will time out and expire. Even if the = device sends an RS again when the screen turns on, connectivity might = have been broken while the screen was off, because the device might have = dropped one or more RAs with a critical update. Devices do need = connectivity while the screen is off - for example, to receive incoming = calls and chat messages. #3 works but not all manufacturers implement = it. Android does this by providing the source code of a bytecode = interpreter to chipset vendors and downloading bytecode to the = interpreter based on previously-received RAs, but some chipset = vendors don't support this. I don't think iOS supports this either. Many = devices do #2. It sort of works as long as the RAs are identical. This = is pretty common because it's easy to do in wifi firmware and pretty = much all wifi chipsets support fixed-function = filtering.

Sure=E2=80=A6

By recommending that lifetimes should be dynamically updated, = this draft will defeat devices that do #2. Based on past experience, a = likely outcome is that manufacturers will react by switching to #1 and = dropping all RAs. We should try to avoid making this problem worse with = this draft.

But = if you don=E2=80=99t update the lifetimes, then you=E2=80=99re handing = out PIOs that contain a lifetime beyond the end of the IA_PD = lease.

Could we perhaps recommend = sending out PIOs that are 1/4 or 1/3 of the original IA_PD lease so long = as the lease is renewed and then dynamically counting down to 0 such = that the PIO never contains a lifetime longer than the IA_PD = validity?

This should provide a best = of both worlds=E2=80=A6 Until the IA_PD expires without renewal, the PIO = should contain a fixed lifetime, but in the (rare) case where a prefix = is expiring, we sacrifice some battery life to avoid a loss of = connectivity.

Alternatively, perhaps = stop issuing PIOs for an IA_PD which has invaded that last fraction of = its lifetime?

The= safest way to do so would be to remove this text. A bit less safe would = be to say that the device must cease to send RAs if the RA lifetime is = below the DHCPv6 PD lifetime. A bit less safe would be to say here that = the device MUST respect RFC 7772 and only send RAs once every few = minutes. (The reason that this isn't super safe is that in a simple = router that just glues together dhcpcd and dnsmasq/radvd, it's not easy = to implement. The DHCPv6 client and the RA daemon are two separate = pieces of software written by different authors, so transferring the = DHCPv6 lifetime to the RA lifetime requires getting the two to = collaborate.) +Timothy = Winters any other = suggestions?

I=E2=80= =99m all for sending RAs less frequently.

I=E2=80=99m not in favor of RA lifetimes exceeding = the DHCPv6 PD lifetime as you advocate at the beginning of this = paragraph. That seems absurd.

Owen


= --Apple-Mail=_4DC4C22B-F9EF-45F2-A701-51403197DA5B-- From nobody Mon Apr 6 14:47:26 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A633A105C for ; Mon, 6 Apr 2020 14:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai1WdYO-4aGE for ; Mon, 6 Apr 2020 14:47:10 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50AF83A0D48 for ; Mon, 6 Apr 2020 14:47:01 -0700 (PDT) Received: from [IPv6:2a01:79d:53aa:d30:68d4:67e1:7951:ee73] (unknown [IPv6:2a01:79d:53aa:d30:68d4:67e1:7951:ee73]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 7E7504E11A5E; Mon, 6 Apr 2020 21:46:59 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Mon, 6 Apr 2020 23:46:56 +0200 Message-Id: <61AA2CA9-FE8A-4ACF-8D77-CABC46C56831@employees.org> References: Cc: v6ops@ietf.org In-Reply-To: To: Philip Homburg X-Mailer: iPhone Mail (17E255) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 21:47:24 -0000 Philip, > On 6 Apr 2020, at 23:17, Philip Homburg wrote= : >=20 > =EF=BB=BF >>=20 >>> That said, setting, the PIO lifetimes in a way that would span past=20 >> the DHCPV6-PD would be incorrect. >>=20 >> Yes, that would violate a fundamental premise of prefix delegation. >=20 > I disagree. In case of a static prefix it should be possible for the > user of the router to set long lifetimes. I am not sure that=E2=80=99s something that can be disagreed with.=20 We specify standards to ensure interoperability. We don=E2=80=99t design pro= ducts. The intention of dhcp pd was that it was a replacement for a fax. And that t= he lifetimes should reflect the length of the contract the user had with a p= rovider.=20 Cheers=20 Ole= From nobody Mon Apr 6 14:54:45 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9667C3A0D13 for ; Mon, 6 Apr 2020 14:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAUHuQf09QdR for ; Mon, 6 Apr 2020 14:54:35 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349F93A0CE6 for ; Mon, 6 Apr 2020 14:53:32 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 3630182D71; Mon, 6 Apr 2020 23:47:58 +0200 (CEST) To: "Bernie Volz (volz)" , "otroan@employees.org" Cc: Ron Bonica , "v6ops@ietf.org" , Timothy Winters References: <52688D39-5537-44BA-B1C8-4341C21D1B02@employees.org> <6186B94B-2504-48C7-8A20-AEB5896D1BB1@employees.org> <56667bf5-97ac-5427-6d75-7ff4f32bf946@si6networks.com> From: Fernando Gont Message-ID: <831536da-bab1-9370-b4db-dd643fa2f022@si6networks.com> Date: Mon, 6 Apr 2020 18:23:03 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 21:54:44 -0000 On 6/4/20 18:15, Bernie Volz (volz) wrote: [....] > Since the DHCPv6-PD client could come back anytime withing the DHCPv6-PD > lease time of the stale prefix, the DHCPv6 server would need to remember > this for such period of time. I assume that's what Bernie meant. > > BV> Correct. The server would be obligated to retain it until the (longest) valid lifetime it had sent the client expired. The question is how the server knows when a DHCP exchange is complete (just because it sent a Reply is not a guarantee the client received it). And, if it does use that then the issue is that this doesn't help the CPE if it rebooted after this (or even) several exchanges as there could still be clients behind the CPE that have not received an updated RA with the deprecated prefix. Completely agree. If anything, this would relieve the CPE from having to store the leased prefix themselves, but: 1) Since the CPE can't know a priori if the DHCPv6 server will, it should record the prefix in order to fail on the safe side. 2) I'm curious what typical CPEs do upon receipt of multiple prefixes via DHCPv6-PD, and also what they do if they receive them, but some have zero lifetimes. (I wouldn't surprise if they only use one, and even less surprised if PIOs with zero lifetimes are simply dropped). Tim? 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 Mon Apr 6 15:03:37 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC643A0D27 for ; Mon, 6 Apr 2020 15:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJFti05hssqr for ; Mon, 6 Apr 2020 15:03:30 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A723E3A0D23 for ; Mon, 6 Apr 2020 15:03:30 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 4FD03893C5; Mon, 6 Apr 2020 23:48:11 +0200 (CEST) To: Owen DeLong , otroan@employees.org Cc: v6ops@ietf.org References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> <5A7E89D4-B4DF-459C-B7CD-38EDAC3AB03D@delong.com> From: Fernando Gont Message-ID: Date: Mon, 6 Apr 2020 18:47:32 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <5A7E89D4-B4DF-459C-B7CD-38EDAC3AB03D@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 22:03:33 -0000 On 6/4/20 18:32, Owen DeLong wrote: [....] > How far do you think we will get if we depend on the intelligence and diligent disciplined implementation of CPE firmware/software? > > Yes, it’s wrong, but I guarantee you it probably does happen in the real world and certainly WILL happen in the real world that PIO lifetimes will be copied from IA_PDs without regard for the amount of time since the lease was issued. > > It’s a stupid mistake, but I bet it becomes a common one as we strive for ever-cheaper devices. Agreed. In fact, I was kind of surprised when many argued that the DHCPv6/SLAAC interface wasn't an issue -- since it's not uncommon t¡for the two pieces of software. IN any case, I think Ole was referring to the case where a *human* manually extends the PIO lifetime past the DHCPv6-PD lease. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 6 15:05:16 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B433A0D2C for ; Mon, 6 Apr 2020 15:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GC7i1Uia; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WMnnnMEq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q1Ov5qD6sHW for ; Mon, 6 Apr 2020 15:05:13 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6383A0D32 for ; Mon, 6 Apr 2020 15:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3606; q=dns/txt; s=iport; t=1586210700; x=1587420300; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hGRtVszOHvRyJfmtGUd3qvgxn6aQeyEU86F5uzFj8eU=; b=GC7i1Uia51XHqjGMfgxuD3uTUFu5RLoUYgUjF1i3O4JhXu0QKgnvz/rB faOhqwKYxUMVZ9Aczr7d2djGJQ+1bfdBoEGk9loWlacSry0/Honfx50M8 NhAYC5hBnGeWeKL1YKfcZslsIZocC6gjwGzk/dBDMIG5eitxprb/ymzCl k=; IronPort-PHdr: =?us-ascii?q?9a23=3A+E/XRRbEbyKfnXPTL6w8GXH/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20QKbRp3VvvRDjeee87vtX2AN+96giDgDa9QNHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuMvnufQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAQD+pote/5hdJa1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4FUUAWBRCAECyoKhBGDRQOKZYJfmB6CUgNUCgEBAQw?= =?us-ascii?q?BAS0CBAEBhEQCF4IyJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVwAQEBAQMSERE?= =?us-ascii?q?MAQE3AQsEAgEIDgMEAQEDAiYCAgIwFQgIAgQBDQUIGoVQAy4BpjECgTmIYnW?= =?us-ascii?q?BMoJ/AQEFhT8Ygg0JgQ4qjDMaggCBVIJNPoJnBIFLAhiDEDKCLI4AgwSIaod?= =?us-ascii?q?Qj2QKgj2NTYl6nAKLQIN3nCUCBAIEBQIOAQEFgWkigVdwFYMkUBgNjh2Dc4p?= =?us-ascii?q?VdAKBJ4tjgTIBMF8BAQ?= X-IronPort-AV: E=Sophos;i="5.72,352,1580774400"; d="scan'208";a="474610914" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Apr 2020 22:04:59 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 036M4xuk018641 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Apr 2020 22:04:59 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 17:04:59 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 17:04:58 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 6 Apr 2020 17:04:58 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EvQBsBCyjS7GX3l9r6bK/uO22wLQDeBLW03er+xGsXlCCNVtCQePAgg89ZNUX2Teguqa56MDflJ0CnSBLSM8+gbIYS6Sbg4XTp4XH+fSvgaZbd08Wk0nGjwWvPxARSFJ9E7xsoAx6UA9ZFNjuIYlJAxw8rbk/1GQISkGBsuUq/xz8Bl/sSU1LWstKqlCZ0OOUASkZFxtpvA+UDa4nFhmjUh/bNq0bFjdcrps1KRE2HTAfXicqs8oMsn4PvN0tkS249nTao+cZ4pu8i+DGHPKzHD6nbODMjAT7Yes2zC08GQZDAXn8cJN2cGbNc6h69qBkBt21Buk8i8MzbzzM/rUhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hGRtVszOHvRyJfmtGUd3qvgxn6aQeyEU86F5uzFj8eU=; b=f9fwqrXsI21tlwOHhx4Lujv5F3QqjmWkYmKO5QezBtIuWK7GotKdmlwiNhss+Lk20piaUcafm+8Cd5SG/gSc1YcNbmmDDvBrDb9nmcpNSFZApjNyram3ZKw+AhK5lncccWt8XgMu/cjCR18tMf4ZXFQQ4Ps9pb8oA7auv0hpU0+1Ibp/7qSCj8biHG7dAqfAi+wRlbCeH3Zm8wsHtx1xHgx//HvQGS3nRz0ojiEzfAZlgLHbx3PxyXRvyzMgKluqtorww6h9s+G/9vRt8u97mMf2Frsdwys2HDwwRvtEtZslEkKACbR5eBfWpLFiOy9ji2dvNryOEMk55KXSG5m+fQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hGRtVszOHvRyJfmtGUd3qvgxn6aQeyEU86F5uzFj8eU=; b=WMnnnMEqVmqIPMgj6h3B59VyhV+1PX7rJqcEkfSi3Qba7vJBVHclEIHKXemvBYK3cD/rqpoIAWPwCDv4uJpHxjd9hMAKCbnmL27EAxImyQN1K5yHQ1EegYdWmKjwFnYhCUVFJFSFG+9OCSlGBAKt40b3mW/HeiMUPApFO1ChS7M= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2546.namprd11.prod.outlook.com (2603:10b6:406:ad::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Mon, 6 Apr 2020 22:04:57 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 22:04:57 +0000 From: "Bernie Volz (volz)" To: Fernando Gont , "otroan@employees.org" CC: Ron Bonica , "v6ops@ietf.org" , Timothy Winters Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdYGqnrRGOoD4f0yRz2uh9FnYboxrQFaGSGAAAIsGEAAAKuIAAAAIs2gAAOzCYAAAdK0gAAAhmmAAAilH4AAAUS4MA== Date: Mon, 6 Apr 2020 22:04:57 +0000 Message-ID: References: <52688D39-5537-44BA-B1C8-4341C21D1B02@employees.org> <6186B94B-2504-48C7-8A20-AEB5896D1BB1@employees.org> <56667bf5-97ac-5427-6d75-7ff4f32bf946@si6networks.com> <831536da-bab1-9370-b4db-dd643fa2f022@si6networks.com> In-Reply-To: <831536da-bab1-9370-b4db-dd643fa2f022@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3ee01921-3b2d-405b-3d09-08d7da768b7e x-ms-traffictypediagnostic: BN7PR11MB2546: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(366004)(346002)(39860400002)(396003)(376002)(7696005)(8936002)(2906002)(478600001)(71200400001)(86362001)(81166006)(81156014)(8676002)(110136005)(54906003)(52536014)(53546011)(316002)(76116006)(26005)(186003)(33656002)(66946007)(5660300002)(6506007)(66476007)(66446008)(64756008)(66556008)(9686003)(55016002)(4326008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Xcv1lM5XebtYrQUC9Aq6sdwTddB3eq5i8jsN1wTzPiqKu8JsYRf0EOg0ZlCYaFvtg/mq9YGpo46A1WCpBefZpsH7rCxY/ZwmSd6jKvgKCvoGgP03RItjmwocN8VaOyHvLE40nQ7VO7DTawIugNmYyOb8ECDwUDhCck/JFUpKLYPvVuq4f7bKjB17X29PoV6OvQRyEXDn9OVxGMDvzFC1qwQjyvibIEtSsFj2Ohqd9c54xxFmcb1syghhy+lUnAv1MxVjLIn9I0jzQ7krla9bqbtvmrrHHgDRgqQAdvewhpVOhCnXck3WwyeFXgAKsEs/feB8XTR7oEsb76ekmc+0OfJf1sGB4dNL2SBpeT1KqY8gIIb3UsUQO/Vq/1aeVLEY5v/shtz+m1fv3HoAycp5h6uMiEMH/1RYRSq8j8k+iK46dtwuv5WbYiK+Mq9DXJPR x-ms-exchange-antispam-messagedata: AYpcMKbFHy9fPMu0r44a5+cI+QslHSbXqjEl6M91+Yyuiy5rBlfN+Q8DI0zkZEj9hMX8B+94ur+85BkbRPUA0oRzXuLLXaQrgMODnRTiQ7wy9xS5Mw/PGmpr7XoY22QXZhkeZ35iqcErWTfqPWgCDg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3ee01921-3b2d-405b-3d09-08d7da768b7e X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 22:04:57.6347 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nAWnj+l2+lDd1PxNfvHC6yqcgqENqicn5E3bL/5zZzv7CsZbvN53SPRqV/kOsE16 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2546 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 22:05:15 -0000 QlRXOiBBbmQgcHJvYmxlbSB0byBwb25kZXIgLi4uDQoNCkNQRSBoYXMgbm8gc3RvcmFnZS4NCg0K REhDUHY2IHNlbmRzIFBEcywgb25lIChvciBzb21lKSB3aXRoIDAgbGlmZXRpbWVzLiBPdGhlcihz KSB3aXRoIG5vbi16ZXJvIGxpZmV0aW1lcy4NCg0KU28sIHdoYXQgc2hvdWxkIGEgQ1BFIGRvPyBI b3cgbG9uZyBzaG91bGQgaXQgY29udGludWUgdG8gc2VuZCBvdXQgdGhlIFJBcyB3aXRoIFBJT3Mg cmVnYXJkaW5nIHRoZSBwcmVmaXhlcyB3aXRoIDAgbGlmZXRpbWVzPw0KDQpJdCB3b3VsZCBoYXZl IHRvIGRvIHRoaXMgdW50aWwgaXQgc3RvcHBlZCByZWNlaXZpbmcgdGhlIFBEcyB3aXRoIDAgbGlm ZXRpbWVzIGluIGEgUmVwbHkgdG8gYSBSZXF1ZXN0LCBSZW5ldywgb3IgUmViaW5kLiBUaGlzIGlz IGJlY2F1c2UgdGhlIENQRSB3b3VsZCBoYXZlIG5vIGtub3dsZWRnZSBvZiB0aGUgb3JpZ2luYWwg bGlmZXRpbWUgYW5kIHdoZW4gdGhhdCBQRCBjb3VsZCBzYWZlbHkgc3RvcCBiZWluZyBhZHZlcnRp c2VkLiBBbmQsIHRoZSBESENQdjYgbWVzc2FnaW5nIGhhcyBubyB3YXkgdG8gY29tbXVuaWNhdGUg d2hhdCB0aGUgb3JpZ2luYWwgKHJlbWFpbmluZykgbGlmZXRpbWUgbWF5IGhhdmUgYmVlbi4NCg0K U28sIHdvdWxkbid0IHRoaXMgbmVlZCB0byBiZSBkb2N1bWVudGVkIHNvbWV3aGVyZT8gT3IgaXMg dGhpcyBzb21ldGhpbmcgd2UgdGhpbmsgZXZlcnlvbmUgaW1wbGVtZW50aW5nIGEgQ1BFIHdvdWxk IHVuZGVyc3RhbmQgaXQgbmVlZHMgdG8gZG8/DQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+ IA0KU2VudDogTW9uZGF5LCBBcHJpbCA2LCAyMDIwIDU6MjMgUE0NClRvOiBCZXJuaWUgVm9seiAo dm9seikgPHZvbHpAY2lzY28uY29tPjsgb3Ryb2FuQGVtcGxveWVlcy5vcmcNCkNjOiBSb24gQm9u aWNhIDxyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+OyB2Nm9wc0BpZXRmLm9y ZzsgVGltb3RoeSBXaW50ZXJzIDx0aW1AcWFjYWZlLmNvbT4NClN1YmplY3Q6IFJlOiBbdjZvcHNd IFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLXY2b3BzLWNwZS1zbGFhYy1yZW51bQ0KDQpPbiA2 LzQvMjAgMTg6MTUsIEJlcm5pZSBWb2x6ICh2b2x6KSB3cm90ZToNClsuLi4uXQ0KPiAgICAgIFNp bmNlIHRoZSBESENQdjYtUEQgY2xpZW50IGNvdWxkIGNvbWUgYmFjayBhbnl0aW1lIHdpdGhpbmcg dGhlIERIQ1B2Ni1QRA0KPiAgICAgIGxlYXNlIHRpbWUgb2YgdGhlIHN0YWxlIHByZWZpeCwgdGhl IERIQ1B2NiBzZXJ2ZXIgd291bGQgbmVlZCB0byByZW1lbWJlcg0KPiAgICAgIHRoaXMgZm9yIHN1 Y2ggcGVyaW9kIG9mIHRpbWUuIEkgYXNzdW1lIHRoYXQncyB3aGF0IEJlcm5pZSBtZWFudC4NCj4g ICAgDQo+IEJWPiBDb3JyZWN0LiBUaGUgc2VydmVyIHdvdWxkIGJlIG9ibGlnYXRlZCB0byByZXRh aW4gaXQgdW50aWwgdGhlIChsb25nZXN0KSB2YWxpZCBsaWZldGltZSBpdCBoYWQgc2VudCB0aGUg Y2xpZW50IGV4cGlyZWQuIFRoZSBxdWVzdGlvbiBpcyBob3cgdGhlIHNlcnZlciBrbm93cyB3aGVu IGEgREhDUCBleGNoYW5nZSBpcyBjb21wbGV0ZSAoanVzdCBiZWNhdXNlIGl0IHNlbnQgYSBSZXBs eSBpcyBub3QgYSBndWFyYW50ZWUgdGhlIGNsaWVudCByZWNlaXZlZCBpdCkuIEFuZCwgaWYgaXQg ZG9lcyB1c2UgdGhhdCB0aGVuIHRoZSBpc3N1ZSBpcyB0aGF0IHRoaXMgZG9lc24ndCBoZWxwIHRo ZSBDUEUgaWYgaXQgcmVib290ZWQgYWZ0ZXIgdGhpcyAob3IgZXZlbikgc2V2ZXJhbCBleGNoYW5n ZXMgYXMgdGhlcmUgY291bGQgc3RpbGwgYmUgY2xpZW50cyBiZWhpbmQgdGhlIENQRSB0aGF0IGhh dmUgbm90IHJlY2VpdmVkIGFuIHVwZGF0ZWQgUkEgd2l0aCB0aGUgZGVwcmVjYXRlZCBwcmVmaXgu DQoNCkNvbXBsZXRlbHkgYWdyZWUuIElmIGFueXRoaW5nLCB0aGlzIHdvdWxkIHJlbGlldmUgdGhl IENQRSBmcm9tIGhhdmluZyB0byBzdG9yZSB0aGUgbGVhc2VkIHByZWZpeCB0aGVtc2VsdmVzLCBi dXQ6DQoNCjEpIFNpbmNlIHRoZSBDUEUgY2FuJ3Qga25vdyBhIHByaW9yaSBpZiB0aGUgREhDUHY2 IHNlcnZlciB3aWxsLCBpdCBzaG91bGQgcmVjb3JkIHRoZSBwcmVmaXggaW4gb3JkZXIgdG8gZmFp bCBvbiB0aGUgc2FmZSBzaWRlLg0KDQoyKSBJJ20gY3VyaW91cyB3aGF0IHR5cGljYWwgQ1BFcyBk byB1cG9uIHJlY2VpcHQgb2YgbXVsdGlwbGUgcHJlZml4ZXMgdmlhIERIQ1B2Ni1QRCwgYW5kIGFs c28gd2hhdCB0aGV5IGRvIGlmIHRoZXkgcmVjZWl2ZSB0aGVtLCBidXQgc29tZSBoYXZlIHplcm8g bGlmZXRpbWVzLiAoSSB3b3VsZG4ndCBzdXJwcmlzZSBpZiB0aGV5IG9ubHkgdXNlIG9uZSwgYW5k IGV2ZW4gbGVzcyBzdXJwcmlzZWQgaWYgUElPcyB3aXRoIHplcm8gbGlmZXRpbWVzIGFyZSBzaW1w bHkgZHJvcHBlZCkuIFRpbT8NCg0KVGhhbmtzIQ0KDQpDaGVlcnMsDQotLQ0KRmVybmFuZG8gR29u dA0KU0k2IE5ldHdvcmtzDQplLW1haWw6IGZnb250QHNpNm5ldHdvcmtzLmNvbQ0KUEdQIEZpbmdl cnByaW50OiA2NjY2IDMxQzYgRDQ4NCA2M0IyIDhGQjEgRTNDNCBBRTI1IDBENTUgMUQ0RSA3NDky DQoNCg0KDQoNCg== From nobody Mon Apr 6 15:06:36 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916463A0D2D for ; Mon, 6 Apr 2020 15:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UW0UawKu9BG for ; Mon, 6 Apr 2020 15:06:33 -0700 (PDT) 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 439F13A0D29 for ; Mon, 6 Apr 2020 15:06:33 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id z5so1014762oth.9 for ; Mon, 06 Apr 2020 15:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bfCDK3ZyYSLCSfC+wO4WfGeBc+RiJm9UJ7qlsNI+DCA=; b=MVUPKhVeFIxxKbiYgLY8qA9TF0fxAG9zoYR1PdHoDqq5xGIxl7TOcWPuO5fy90Rmgx cuqvK7EQBGy53yFmZGNoLI4D933WWqVqUD8Z2xVLKCSD3rGI4Ckj4SU8R0LPDglWB2ng oAxFOn+hxCWpkHZIbZ96FIiq3UzhlntLzoc0VRCIuO59SdwVu3RtJy/rToJEJxAg7hZx JlaQJNpegyr3HnjjGYgnr+lq7gUGcUf45ym23YBDhSyIKas4sHjpnN3v/zaKYcXyN0AN 2mDX8ZVu/VSIUp+dGhs99gPCs0lI5ZtV/5MTkPY/Aw2O0DGUzOuGWLHRPHZMXOdvPRvJ uflQ== 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=bfCDK3ZyYSLCSfC+wO4WfGeBc+RiJm9UJ7qlsNI+DCA=; b=ZzrWhWeXJ5t82IBUG3oq4n71bqg1pO3vz0PGe5CVNLb8nJJg1KvGfok/+NgDCYzi6H kJLN0RpaHY2roR+jPhBw4tVn+r6Bw7c2SdVorHrZ8wXpt4dfv8A+KDq0+Cd19wkbFU/n lmyTJPy5hvo6acLqwu9elBqtqziyrxlUGY56zrVx3241iyyM4hvdf/b8MkgqA5Ive495 2eSp2STsNnQPQfFca32FkcvVP3XEwWDaoQN077KZnht6CjJ5Wa0BFECoZSLaZle/kpRP tai9uY9PPu49C1/8TWRR80v4PnM5ojdSFzp94ZZEU0qh6trMtbsiAFFA6za1pHtq+w96 Y38Q== X-Gm-Message-State: AGi0PuaWgf6m9ey/9t/SBgi2dQ/nm5Vd9vdOqfp5qu0MVGU1Q0uuQsrD xFuzAh61bsBOOuZMQ27hwRu8cvLVtYey+rqLMdAQhg== X-Google-Smtp-Source: APiQypKQy+LfmfWPYkj5xCTWoB0bO5uvwRXGcDZ28Az5iNNGeHY1nT80LTO8dwb39aUIPvbmyFcNgfD9fgdfLoILSwM= X-Received: by 2002:a05:6830:4035:: with SMTP id i21mr18069488ots.348.1586210792402; Mon, 06 Apr 2020 15:06:32 -0700 (PDT) MIME-Version: 1.0 References: <61AA2CA9-FE8A-4ACF-8D77-CABC46C56831@employees.org> In-Reply-To: <61AA2CA9-FE8A-4ACF-8D77-CABC46C56831@employees.org> From: Mark Smith Date: Tue, 7 Apr 2020 08:06:06 +1000 Message-ID: To: Ole Troan Cc: Philip Homburg , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 22:06:35 -0000 On Tue, 7 Apr 2020 at 07:50, Ole Troan wrote: > > Philip, > > > On 6 Apr 2020, at 23:17, Philip Homburg wr= ote: > > > > =EF=BB=BF > >> > >>> That said, setting, the PIO lifetimes in a way that would span past > >> the DHCPV6-PD would be incorrect. > >> > >> Yes, that would violate a fundamental premise of prefix delegation. > > > > I disagree. In case of a static prefix it should be possible for the > > user of the router to set long lifetimes. > > I am not sure that=E2=80=99s something that can be disagreed with. > We specify standards to ensure interoperability. We don=E2=80=99t design = products. > > The intention of dhcp pd was that it was a replacement for a fax. And tha= t the lifetimes should reflect the length of the contract the user had with= a provider. > Agree. The PD address space isn't the end-users', it's on-loan from their ISP, so their ISP is the party to choose how long it is on loan for. CPE should be following and enforcing this loan term by decrementing PD lifetimes in its LAN interface RAs. Internal ULA address space provides the address stability that would be being sought by a mechanism to override an ISP's PD prefix lifetimes. Regards, Mark. > Cheers > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Apr 6 15:11:40 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056CF3A0D4A for ; Mon, 6 Apr 2020 15:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TrnshG9Y; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Pk7X95eX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0IyWUwRSTaD for ; Mon, 6 Apr 2020 15:11:37 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526943A0D45 for ; Mon, 6 Apr 2020 15:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2838; q=dns/txt; s=iport; t=1586211097; x=1587420697; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=P01C3zzOkEXRL+tmVz8DLQZfMFJcOuqqI5/8Z0bLVQ8=; b=TrnshG9Y/dIbdXEWFS2P8HF63r025x22ARj1PHJETQbVrfnwfdKZUMqn Aw/HvAmLQe7/TwTpkRlBL6MSY6Hfd8ck6cFIUI/no4Pz46y3RFoWJ5UOb 3A/Z4jDJAyuIbBdf/bqs1vwMQWwaESpnsIl4RBfXyEUhWmg8W+Dv+9Lxj 0=; IronPort-PHdr: =?us-ascii?q?9a23=3A6K2LXRUXzuJ1Nf1ueS+ACSB3HIHV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANiJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dEwd4TgxRmBceEDUPhK/u/cSs+DuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAADRqIte/5NdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gVRQBWxYIAQLKgqEEYNFA4pmgl+YHoJSA1Q?= =?us-ascii?q?KAQEBDAEBGAsKAgQBAYREAheCMiQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFcAE?= =?us-ascii?q?BAQECAQEBEBERDAEBLAsBBAcEAgEIEQQBAQECAiYCAgIlCxUICAIEAQ0FCBq?= =?us-ascii?q?DBYJLAw4gAQ6mJwKBOYhidYEygn8BAQWBLwGEDhiCDQMGgQ4qjDMaggCBVIJ?= =?us-ascii?q?NPoJnAQGBZ4MQMoIsjiyCWKAeCoI9l0ecAotAg3ecJQIEAgQFAg4BAQWBaSK?= =?us-ascii?q?BV3AVO4JpUBgNjh0MF4NQhRSFQXSBKY0VAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.72,352,1580774400"; d="scan'208";a="661479923" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Apr 2020 22:11:18 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 036MBIiT005682 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Apr 2020 22:11:18 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 17:11:18 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 17:11:17 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 6 Apr 2020 17:11:17 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GeSInA65tq/u92kA2M0xiStyRUybUrdrnhft/gar8go5KlosT+hKoH5WzoH7d6xuetUSNbRKrjaziTL7Dy/oorTX/XptE6ZszUwkQN3ZMM7gqdnImd9Pu/ygLbJ6YlPmtD8C5w0mt8nHZwpVXlOpO+BTH6nKkOQ0M+WnVnE0HDqIRYYZ9i37sKzjZqhQBSPvHokqI6g76FbKaOH2wxOuRoG7faxsJE7Piy9gunDiADUY0WjUKQGPFaCCeKem3YvUWW6/vFR6KCNH9g2+UIyEnO3B0wDBLm2yDBKxGgIMdNuoKYeSE1j+ub9CzbVNkmEyMgaZzYDN2+86D22o6vWgWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P01C3zzOkEXRL+tmVz8DLQZfMFJcOuqqI5/8Z0bLVQ8=; b=CqILO3+MzKE9aPI5/WIa22ghXJfjHyasQXfADdjYquqnfvidixH02ULLkdqiT89JcRwuNK3EiAioU2f8c3x1fdV3Ijhd1/n6YznQlnaQ+YPQqySLhIBxbISizf3SrZo+MuaQyO0vLuagzvnmIA0VpN/S/z76ORuimuzsgSsYUqjJnKlnfLerUkiGVyBDnBK6AJC9X65DQbR+3XXq/0qu5oqTOVKmYrVitzwZklrfl3e3dA5gzvQEvIzUzqfXdZSb+DqVTNK5kT6DbXFpr+ZE6qsxffQZm4r9NMilqKSyB3mOntc6w+JbQk3Qqc9jCTeOLmrEsaVmDc4gVgavTfK+EA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P01C3zzOkEXRL+tmVz8DLQZfMFJcOuqqI5/8Z0bLVQ8=; b=Pk7X95eXSCVmYtdhrJ0uVcJxxrl36X9ikIo1UWlZCbohYcqZGwQ7x9y4wfk0yVzq36DGHk7OUPS+k0/TlmKxofd9QRwHJFQL+KnPwsChuJsjOZUNM1ajFIGY1rLcH+MzoIho3f0AuPVC0UySVTIxI33qTbFZYBFwpmeovACZIAU= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Mon, 6 Apr 2020 22:11:16 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 22:11:16 +0000 From: "Bernie Volz (volz)" To: Mark Smith , Ole Troan CC: v6ops list Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AQHWC34Vl4y0XZJUoU+JpKF7oC9Nvahq+S8AgAE2Gu6AAAs2AIAAB4+AgABYvr+AAAgAAIAABVsAgAAA0sA= Date: Mon, 6 Apr 2020 22:11:16 +0000 Message-ID: References: <61AA2CA9-FE8A-4ACF-8D77-CABC46C56831@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 83d533d1-6337-411e-7ef7-08d7da776d75 x-ms-traffictypediagnostic: BN7PR11MB2547: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(39860400002)(346002)(136003)(376002)(366004)(26005)(86362001)(966005)(478600001)(8936002)(186003)(110136005)(4326008)(71200400001)(81156014)(8676002)(81166006)(316002)(64756008)(76116006)(5660300002)(33656002)(66446008)(55016002)(9686003)(52536014)(66556008)(7696005)(66476007)(66946007)(66574012)(53546011)(2906002)(6506007); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8ezDg42TZ8WA/lDAcrwxsiP1FFn9ptEyIAgFUljnEUBpj/9E/JWjEaEuvXfBgurQwE7CciNF6e6pkmvtczeddR7Qz1zrX4EOfEjuqhdwkRsr0ryFJXQoTNUV4R44RRWuyab/ZRmINmO6OlQVNf1SVFwcK8+pNnaoZxHtH2EDPu2vn6akRZcKcqOQkbmPQc1aapwh66hLTN3jYHdtI98SQObfhoFM9AU0P+27ltpGHQPf6kfDqTkxtzUiZGcSuvRv4o8ujJHzrd6maJzov3B9Vb62WCzk/AwNdRvNyLmqOiz3ZaEVUa9BCP24DgrxzOYOtUgvdBWpFjV7jxxMLBscvdwA0g0+F3KBKF1meEubyPf8ryfquTKQMKL2W9ioTzh7UA77HNl1JVswbpB8dh9liVAQ9E8xdsWQq2IOzPINGzZQ3ksLBokOG0neCj4lsOAB9iY789ftb63IfOVSMbmETtrITK4rxUDshUKZOTB/82ZknlQ93Vk4cEtFmPBdh5CjSIKKFEmltJ3IgM04AkZUIg== x-ms-exchange-antispam-messagedata: aNYIFrPgSdwRwMF5tukGHLyNBTILwBXivpFa82xx2L2IKYt0h94/T2L08n+R9qwePbOX3mN6km+4xz+3xfblMR/8R9xv4ZsDeF9/pnugD0Tm2l914B1Q3H6ddBrxKQMuzNvxjbrwnIdXZRKKr3s4YQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 83d533d1-6337-411e-7ef7-08d7da776d75 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 22:11:16.7625 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Jezvi4L4BT+1U4IiIT7OByzewyel642ieyzGfkfagQp6RKoIv0J76b2w4iQb/F3y X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2547 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 22:11:39 -0000 QW5kLCBpZiB0aGlzIGlzIHRydWx5IGEgZml4ZWQgcHJlZml4LCBsaWtlbHkgeW91IGNvdWxkIHJl bW92ZSB0aGUgbmVlZCBmb3IgREhDUHY2IChkaXNjdXNzIHdpdGggc2VydmljZSBwcm92aWRlZCkg YW5kIGp1c3QgbWFudWFsbHkgY29uZmlndXJlIGl0IGF0IHRoZSBDUEUgZW5kPw0KDQpJZiB0aGUg dG9vbCB5b3UgYXJlIHVzaW5nIGRvZXNuJ3QgZ2l2ZSB5b3Ugd2hhdCB5b3UgbmVlZCwgdXNlIGEg ZGlmZmVyZW50IHRvb2wuDQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1hcmsg U21pdGgNClNlbnQ6IE1vbmRheSwgQXByaWwgNiwgMjAyMCA2OjA2IFBNDQpUbzogT2xlIFRyb2Fu IDxvdHJvYW5AZW1wbG95ZWVzLm9yZz4NCkNjOiB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbdjZvcHNdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLXY2b3BzLWNw ZS1zbGFhYy1yZW51bQ0KDQpPbiBUdWUsIDcgQXByIDIwMjAgYXQgMDc6NTAsIE9sZSBUcm9hbiA8 b3Ryb2FuQGVtcGxveWVlcy5vcmc+IHdyb3RlOg0KPg0KPiBQaGlsaXAsDQo+DQo+ID4gT24gNiBB cHIgMjAyMCwgYXQgMjM6MTcsIFBoaWxpcCBIb21idXJnIDxwY2gtdjZvcHMtOUB1LTEucGhpY29o LmNvbT4gd3JvdGU6DQo+ID4NCj4gPiDvu78NCj4gPj4NCj4gPj4+IFRoYXQgc2FpZCwgc2V0dGlu ZywgdGhlIFBJTyBsaWZldGltZXMgaW4gYSB3YXkgdGhhdCB3b3VsZCBzcGFuIA0KPiA+Pj4gcGFz dA0KPiA+PiB0aGUgREhDUFY2LVBEIHdvdWxkIGJlIGluY29ycmVjdC4NCj4gPj4NCj4gPj4gWWVz LCB0aGF0IHdvdWxkIHZpb2xhdGUgYSBmdW5kYW1lbnRhbCBwcmVtaXNlIG9mIHByZWZpeCBkZWxl Z2F0aW9uLg0KPiA+DQo+ID4gSSBkaXNhZ3JlZS4gSW4gY2FzZSBvZiBhIHN0YXRpYyBwcmVmaXgg aXQgc2hvdWxkIGJlIHBvc3NpYmxlIGZvciB0aGUgDQo+ID4gdXNlciBvZiB0aGUgcm91dGVyIHRv IHNldCBsb25nIGxpZmV0aW1lcy4NCj4NCj4gSSBhbSBub3Qgc3VyZSB0aGF04oCZcyBzb21ldGhp bmcgdGhhdCBjYW4gYmUgZGlzYWdyZWVkIHdpdGguDQo+IFdlIHNwZWNpZnkgc3RhbmRhcmRzIHRv IGVuc3VyZSBpbnRlcm9wZXJhYmlsaXR5LiBXZSBkb27igJl0IGRlc2lnbiBwcm9kdWN0cy4NCj4N Cj4gVGhlIGludGVudGlvbiBvZiBkaGNwIHBkIHdhcyB0aGF0IGl0IHdhcyBhIHJlcGxhY2VtZW50 IGZvciBhIGZheC4gQW5kIHRoYXQgdGhlIGxpZmV0aW1lcyBzaG91bGQgcmVmbGVjdCB0aGUgbGVu Z3RoIG9mIHRoZSBjb250cmFjdCB0aGUgdXNlciBoYWQgd2l0aCBhIHByb3ZpZGVyLg0KPg0KDQpB Z3JlZS4gVGhlIFBEIGFkZHJlc3Mgc3BhY2UgaXNuJ3QgdGhlIGVuZC11c2VycycsIGl0J3Mgb24t bG9hbiBmcm9tIHRoZWlyIElTUCwgc28gdGhlaXIgSVNQIGlzIHRoZSBwYXJ0eSB0byBjaG9vc2Ug aG93IGxvbmcgaXQgaXMgb24gbG9hbiBmb3IuIENQRSBzaG91bGQgYmUgZm9sbG93aW5nIGFuZCBl bmZvcmNpbmcgdGhpcyBsb2FuIHRlcm0gYnkgZGVjcmVtZW50aW5nIFBEIGxpZmV0aW1lcyBpbiBp dHMgTEFOIGludGVyZmFjZSBSQXMuDQoNCkludGVybmFsIFVMQSBhZGRyZXNzIHNwYWNlIHByb3Zp ZGVzIHRoZSBhZGRyZXNzIHN0YWJpbGl0eSB0aGF0IHdvdWxkIGJlIGJlaW5nIHNvdWdodCBieSBh IG1lY2hhbmlzbSB0byBvdmVycmlkZSBhbiBJU1AncyBQRCBwcmVmaXggbGlmZXRpbWVzLg0KDQpS ZWdhcmRzLA0KTWFyay4NCg0KPiBDaGVlcnMNCj4gT2xlDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9w c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9w cyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Mon Apr 6 15:27:30 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D9B3A0D97 for ; Mon, 6 Apr 2020 15:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfIVY1F-EJdl for ; Mon, 6 Apr 2020 15:27:27 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B41D3A0D8B for ; Mon, 6 Apr 2020 15:27:26 -0700 (PDT) Received: from [IPv6:2a01:79d:53aa:d30:68d4:67e1:7951:ee73] (unknown [IPv6:2a01:79d:53aa:d30:68d4:67e1:7951:ee73]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 09F1A4E11B0A; Mon, 6 Apr 2020 22:27:25 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Tue, 7 Apr 2020 00:27:23 +0200 Message-Id: <89BE3606-0DBF-4D1E-B2E2-EA6862950453@employees.org> References: Cc: Mark Smith , v6ops list In-Reply-To: To: "Bernie Volz (volz)" X-Mailer: iPhone Mail (17E255) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 22:27:29 -0000 Bernie, > =EF=BB=BFAnd, if this is truly a fixed prefix, likely you could remove the= need for DHCPv6 (discuss with service provided) and just manually configure= it at the CPE end? DHCP PD was designed for the =E2=80=9Cfixed=E2=80=9D use case. I.e fixed as i= n lifetime equal contract. DHCP PD is a fax replacement. The concern was tha= t few users would be able to type 48-56 bits correctly.=20 If it wasn=E2=80=99t for that use case DHCPv6 might never have got off the g= round in the first place. ;-) Cheers=20 Ole >=20 > If the tool you are using doesn't give you what you need, use a different t= ool. >=20 > - Bernie >=20 > -----Original Message----- > From: v6ops On Behalf Of Mark Smith > Sent: Monday, April 6, 2020 6:06 PM > To: Ole Troan > Cc: v6ops list > Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum >=20 >> On Tue, 7 Apr 2020 at 07:50, Ole Troan wrote: >>=20 >> Philip, >>=20 >>>> On 6 Apr 2020, at 23:17, Philip Homburg wr= ote: >>>=20 >>> =EF=BB=BF >>>>=20 >>>>> That said, setting, the PIO lifetimes in a way that would span=20 >>>>> past >>>> the DHCPV6-PD would be incorrect. >>>>=20 >>>> Yes, that would violate a fundamental premise of prefix delegation. >>>=20 >>> I disagree. In case of a static prefix it should be possible for the=20 >>> user of the router to set long lifetimes. >>=20 >> I am not sure that=E2=80=99s something that can be disagreed with. >> We specify standards to ensure interoperability. We don=E2=80=99t design p= roducts. >>=20 >> The intention of dhcp pd was that it was a replacement for a fax. And tha= t the lifetimes should reflect the length of the contract the user had with a= provider. >>=20 >=20 > Agree. The PD address space isn't the end-users', it's on-loan from their I= SP, so their ISP is the party to choose how long it is on loan for. CPE shou= ld be following and enforcing this loan term by decrementing PD lifetimes in= its LAN interface RAs. >=20 > Internal ULA address space provides the address stability that would be be= ing sought by a mechanism to override an ISP's PD prefix lifetimes. >=20 > Regards, > Mark. >=20 >> Cheers >> Ole >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Apr 6 16:37:17 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D367B3A073E for ; Mon, 6 Apr 2020 16:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qacafe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3UlUxMRRGvS for ; Mon, 6 Apr 2020 16:37:15 -0700 (PDT) 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 351B13A0743 for ; Mon, 6 Apr 2020 16:37:15 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id a25so1741594wrd.0 for ; Mon, 06 Apr 2020 16:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FUT+rm0sxNOs7g8C17Bboxf/GQ2S9GlTb6FUoDBuE7E=; b=N6Hgj69kEPz0+JCj5zeu0+As9DLx2wTZIp46xcr85OaRiWS2NuDEM1cGulsFD+zkMT C1angAmJL2fHr4rQemYswKLY20tgqbOuOh0nEFLiluSLvqZnRD23bAob2LAzWgxaEoDB mCtiVyXaTUUDN4OUpK1c6APtGIrJNma72jngU= 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=FUT+rm0sxNOs7g8C17Bboxf/GQ2S9GlTb6FUoDBuE7E=; b=d027gixGyAmZe9Oo39AGuSkJzy/tGyjl6H63gwilUxI0KnKf7Xv4/sVzPOEO1A8IPb DpiohC+kkVwbwL1oJD+HUSXv1LXv8aL+Gzje6H5Cy2BtQcquIYCnhnKUAlOKS1Fp5mDZ qpRg6Yw7AeeGFpxxYHyr++98/t1W7//SeEwe5dLYPurusFxHkHQGSwIcnyhTVOUSpekV dG162wmurk2Zbx57HZ7cdU8CzCNG89xULB6PlRRMq9N1MkQ++nNtmxJbqfdd8FEs+h4A 9fTV1GE+Ruh9HJ/5ufyKzYFsyxAUfoEoIqCPD5dAJhgj5j9uge8akj0pHbDCpRmOB1lF APHw== X-Gm-Message-State: AGi0PuZKCgPerlZ69UscLYxoP8xxv/ekHPPGmGQhnMF00uVl9R63Pp6p 73S2KfXV7Y1jmBjQcG5L940p0J/x/WxVWlSA2T45ZQ== X-Google-Smtp-Source: APiQypL0woOOF0SeIhBVlitx77WLj2jdTN9RC8kyH7auTMFNzP7w8BksgGmW99mvq2vCW4/27c8mRGnGYeL+PJVQpvA= X-Received: by 2002:a5d:474b:: with SMTP id o11mr1669346wrs.391.1586216233447; Mon, 06 Apr 2020 16:37:13 -0700 (PDT) MIME-Version: 1.0 References: <52688D39-5537-44BA-B1C8-4341C21D1B02@employees.org> <6186B94B-2504-48C7-8A20-AEB5896D1BB1@employees.org> <56667bf5-97ac-5427-6d75-7ff4f32bf946@si6networks.com> <831536da-bab1-9370-b4db-dd643fa2f022@si6networks.com> In-Reply-To: <831536da-bab1-9370-b4db-dd643fa2f022@si6networks.com> From: Timothy Winters Date: Mon, 6 Apr 2020 19:37:02 -0400 Message-ID: To: Fernando Gont Cc: "Bernie Volz (volz)" , "otroan@employees.org" , Ron Bonica , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000021cfd805a2a7bf3a" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 23:37:17 -0000 --00000000000021cfd805a2a7bf3a Content-Type: text/plain; charset="UTF-8" On Mon, Apr 6, 2020 at 5:48 PM Fernando Gont wrote: > On 6/4/20 18:15, Bernie Volz (volz) wrote: > [....] > > Since the DHCPv6-PD client could come back anytime withing the > DHCPv6-PD > > lease time of the stale prefix, the DHCPv6 server would need to > remember > > this for such period of time. I assume that's what Bernie meant. > > > > BV> Correct. The server would be obligated to retain it until the > (longest) valid lifetime it had sent the client expired. The question is > how the server knows when a DHCP exchange is complete (just because it sent > a Reply is not a guarantee the client received it). And, if it does use > that then the issue is that this doesn't help the CPE if it rebooted after > this (or even) several exchanges as there could still be clients behind the > CPE that have not received an updated RA with the deprecated prefix. > > Completely agree. If anything, this would relieve the CPE from having to > store the leased prefix themselves, but: > > 1) Since the CPE can't know a priori if the DHCPv6 server will, it > should record the prefix in order to fail on the safe side. > > 2) I'm curious what typical CPEs do upon receipt of multiple prefixes > via DHCPv6-PD, and also what they do if they receive them, but some have > zero lifetimes. (I wouldn't surprise if they only use one, and even less > surprised if PIOs with zero lifetimes are simply dropped). Tim? > IPv6 Ready has a test for Prefix Change that sends IA_PDs with one valid and one with zero. So we test and IPv6 Ready Logo CE Routers do this perfectly. When I was at the lab this was the most failed test case, in all the ways you can imagine. I came to really hate this test case over the last 4 four years. > > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --00000000000021cfd805a2a7bf3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 6, 2020 at 5:48 PM Fernan= do Gont <fgont@si6networks.com<= /a>> wrote:
O= n 6/4/20 18:15, Bernie Volz (volz) wrote:
[....]
>=C2=A0 =C2=A0 =C2=A0 Since the DHCPv6-PD client could come back anytime= withing the DHCPv6-PD
>=C2=A0 =C2=A0 =C2=A0 lease time of the stale prefix, the DHCPv6 server = would need to remember
>=C2=A0 =C2=A0 =C2=A0 this for such period of time. I assume that's = what Bernie meant.
>=C2=A0 =C2=A0
> BV> Correct. The server would be obligated to retain it until the (= longest) valid lifetime it had sent the client expired. The question is how= the server knows when a DHCP exchange is complete (just because it sent a = Reply is not a guarantee the client received it). And, if it does use that = then the issue is that this doesn't help the CPE if it rebooted after t= his (or even) several exchanges as there could still be clients behind the = CPE that have not received an updated RA with the deprecated prefix.

Completely agree. If anything, this would relieve the CPE from having to store the leased prefix themselves, but:

1) Since the CPE can't know a priori if the DHCPv6 server will, it
should record the prefix in order to fail on the safe side.

2) I'm curious what typical CPEs do upon receipt of multiple prefixes <= br> via DHCPv6-PD, and also what they do if they receive them, but some have zero lifetimes. (I wouldn't surprise if they only use one, and even les= s
surprised if PIOs with zero lifetimes are simply dropped). Tim?
IPv6 Ready has a test for Prefix Change that sends IA_PDs with on= e valid and one with zero.=C2=A0 So we test=C2=A0and IPv6 Ready Logo CE Rou= ters=C2=A0do this perfectly.=C2=A0 When I was at the lab this was the most = failed test case, in all the ways you can imagine.=C2=A0 I came to really h= ate this test case over the last 4 four years.

Thanks!

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




--00000000000021cfd805a2a7bf3a-- From nobody Mon Apr 6 16:47:25 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622493A0FB2 for ; Mon, 6 Apr 2020 16:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 zp-Sl7MAY1wD for ; Mon, 6 Apr 2020 16:47:21 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9943A0FB6 for ; Mon, 6 Apr 2020 16:47:20 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 C5612832B1; Tue, 7 Apr 2020 01:47:16 +0200 (CEST) To: Timothy Winters Cc: "Bernie Volz (volz)" , "otroan@employees.org" , Ron Bonica , "v6ops@ietf.org" References: <52688D39-5537-44BA-B1C8-4341C21D1B02@employees.org> <6186B94B-2504-48C7-8A20-AEB5896D1BB1@employees.org> <56667bf5-97ac-5427-6d75-7ff4f32bf946@si6networks.com> <831536da-bab1-9370-b4db-dd643fa2f022@si6networks.com> From: Fernando Gont Message-ID: <42c901f8-7a67-1999-1210-272656ef6c9f@si6networks.com> Date: Mon, 6 Apr 2020 20:46:47 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2020 23:47:24 -0000 On 6/4/20 20:37, Timothy Winters wrote: [...] > > 2) I'm curious what typical CPEs do upon receipt of multiple prefixes > via DHCPv6-PD, and also what they do if they receive them, but some > have > zero lifetimes. (I wouldn't surprise if they only use one, and even > less > surprised if PIOs with zero lifetimes are simply dropped). Tim? > > IPv6 Ready has a test for Prefix Change that sends IA_PDs with one valid > and one with zero.  So we test and IPv6 Ready Logo CE Routers do this > perfectly.  When I was at the lab this was the most failed test case, in > all the ways you can imagine.  I came to really hate this test case over > the last 4 four years. Failed on the CPE side, router side, or both? And... any idea if this ever improved significantly? Or show we still assume CPEs to be buggy in this respect? Thanks! -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 7 01:02:02 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA183A18AA for ; Tue, 7 Apr 2020 01:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd92S8wPcA3O for ; Tue, 7 Apr 2020 01:01:59 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2883A18A9 for ; Tue, 7 Apr 2020 01:01:58 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jLjB5-0000LFC; Tue, 7 Apr 2020 10:01:47 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <61AA2CA9-FE8A-4ACF-8D77-CABC46C56831@employees.org> In-reply-to: Your message of "Mon, 6 Apr 2020 23:46:56 +0200 ." <61AA2CA9-FE8A-4ACF-8D77-CABC46C56831@employees.org> Date: Tue, 07 Apr 2020 10:01:40 +0200 Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 08:02:01 -0000 > I am not sure thats something that can be disagreed with. We > specify standards to ensure interoperability. We dont design > products. > > The intention of dhcp pd was that it was a replacement for a fax. > And that the lifetimes should reflect the length of the contract > the user had with a provider. Then the real world happened and ISPs use DHCPv6 PD to manage FIB entries in their access routers. I.e. they store customer prefixes in a radius server and have DHCPv6 PD distribute the routes. If your CPE doesn't do DHCPv6 PD then no FIB so no joy. We should not design specifications that prevent the user from overriding the system in cases where it is harmless to do so. From nobody Tue Apr 7 01:27:14 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D363A18F7 for ; Tue, 7 Apr 2020 01:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxNnnMDM3gPR for ; Tue, 7 Apr 2020 01:27:11 -0700 (PDT) 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 3B0713A0A5B for ; Tue, 7 Apr 2020 01:27:11 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id a49so2208594otc.11 for ; Tue, 07 Apr 2020 01:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fosssDyjElYJThNibuFNAV+wGGd8w+3T6S0cBsRdNIs=; b=aNPn+CTo3UlaLaSiDydllS0PNXab9UP4xybB0rQUMyWdoMpNdFaW1JKk/o6Mb386Jj qjKXgQz5O3jMcu+49o/QMYyGbeFyuy5+AvVVI12OXnhQ7PDcCbppnDFJ2ubVskKmWr82 beB+B/C/OUqZk9SJSq9ziWYQkdmVjI6KqEBq+DmJv4NEXewucEJ3UYTe8pCatg0brXvt KZbfJafdjLcmuPjB6RzlyR1Jnb916cAnj85xXbd90rv2fvg1S/AeGeJFN/L7hglGJUmW zdv8AMRUCApBgohz3DGrFiKd4uXhJ8V8gQYEpiBDKy5yLnRk41qiR3WbqG2zJ24ItIIY 1ysw== 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=fosssDyjElYJThNibuFNAV+wGGd8w+3T6S0cBsRdNIs=; b=ReeIm2mupLBQotvJV/OIUqSYGzs/lNWszVfqy9mW1IV9cwDFzX2i8pAhe/tHuh3/WI Ov0TxrKq9BvJtmYYPTi5h5SeBVMI63Gxl3DZxYKKvrwWbX4a8WmFJydPW0HkpO/icSLU PxG5RIRnkccnjIfXnogv9EIDqvNW8nTOz3V8YB9Wq1fu4EBRn1dSXDUd8jE6z0KG+pyG 9JxUX2yLHGP/E4MWPnPB+7Yn4eT+EoknBkEyvMI0QZdI9m8Hi0uJGND35+vrVecrWs3I 7LrNWhm8228af6DwSO8K0nhmJHbXV1Xj0F2/FaOoPEpm7wYTtaIkrZgwXUjkYwkErd+D Qnmw== X-Gm-Message-State: AGi0PuaFdlDrByPNZjgt2+eLuHJACTrXgoTsZjOuVs4tdpVkCqwgCKqA nIGcSb31eyTX9HM5wqM1bnenx+ZAKiHseW1pGKZj4A== X-Google-Smtp-Source: APiQypI6NQXSdU/y4/0uhn5GrINCuxdMAIYwlRPxsXtS0ciueiyWMH+ggYBdAH5txBdSa9nalHiLd3JDhewU+bH7VZA= X-Received: by 2002:a9d:1402:: with SMTP id h2mr493329oth.74.1586248030260; Tue, 07 Apr 2020 01:27:10 -0700 (PDT) MIME-Version: 1.0 References: <61AA2CA9-FE8A-4ACF-8D77-CABC46C56831@employees.org> In-Reply-To: From: Mark Smith Date: Tue, 7 Apr 2020 18:26:59 +1000 Message-ID: To: Philip Homburg Cc: v6ops list Content-Type: multipart/alternative; boundary="0000000000005e904605a2af261b" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 08:27:13 -0000 --0000000000005e904605a2af261b Content-Type: text/plain; charset="UTF-8" On Tue, 7 Apr 2020, 18:02 Philip Homburg, wrote: > > I am not sure thats something that can be disagreed with. We > > specify standards to ensure interoperability. We dont design > > products. > > > > The intention of dhcp pd was that it was a replacement for a fax. > > And that the lifetimes should reflect the length of the contract > > the user had with a provider. > > Then the real world happened and ISPs use DHCPv6 PD to manage FIB entries > in > their access routers. > > I.e. they store customer prefixes in a radius server and have DHCPv6 PD > distribute the routes. If your CPE doesn't do DHCPv6 PD then no FIB so no > joy. > > We should not design specifications that prevent the user from overriding > the > system in cases where it is harmless to do so. Imagine a home user continuing to try to illegitimately use as a source address what is now somebody else's PD prefix because they overrode the ISP's lifetimes. It's not harmless. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6 > > --0000000000005e904605a2af261b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 7 Apr 2020, 18:02 Philip Homburg, <pch-v6ops-9@u-1.phicoh.com> w= rote:
> I am not sure thats some= thing that can be disagreed with.=C2=A0 We
> specify standards to ensure interoperability. We dont design
> products.
>
> The intention of dhcp pd was that it was a replacement for a fax.
> And that the lifetimes should reflect the length of the contract
> the user had with a provider.

Then the real world happened and ISPs use DHCPv6 PD to manage FIB entries i= n
their access routers.

I.e. they store customer prefixes in a radius server and have DHCPv6 PD
distribute the routes. If your CPE doesn't do DHCPv6 PD then no FIB so = no joy.

We should not design specifications that prevent the user from overriding t= he
system in cases where it is harmless to do so.

Imagine a home user continuing to= try to illegitimately use as a source address what is now somebody else= 9;s PD prefix because they overrode the ISP's lifetimes.

It's not harmless.


_______________________________________________
v6ops mailing list
v6op= s@ietf.org
https://www.ietf.org/mailman/listinfo/v6
--0000000000005e904605a2af261b-- From nobody Tue Apr 7 06:49:19 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681B73A0C69 for ; Tue, 7 Apr 2020 06:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 XoqNmYb8o_um for ; Tue, 7 Apr 2020 06:49:11 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C983A0B81 for ; Tue, 7 Apr 2020 06:48:56 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id k29so3243808ilg.0 for ; Tue, 07 Apr 2020 06:48:56 -0700 (PDT) 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=kHj+b8RHvsTX7k50kt7WXWdFA+kgKCNEYLolpRgRrAo=; b=d5i1aU1yGGZ2GEWAagyzUVEra92W9l3dJMmaxvDH4o9u7wX2kmFbO5YR/uAjKwKD6N UN1f0sLl+6SJZgAGjbs98UB5UKCKs0bQDoXVqZSNAcw3iouJEvUkPbH0J/GpPuUVtOqj YwtjKMtAzMHYys2gQZzvvLRdNSvunGnjNVRiO/CvQhr3PeC2v1eLAEkmzyt96O4R+EJD I1GBkoyNTUbB3CfL3hU5RwvDSKGE8qjJsbwEZjo9ebJacFByfKaUXQ0AQy1569vjfuJ9 5Jj0pedna6zSsraQqwlZRY+oj+C0lF/d3tDM2sSWgOXhesMF5iz87xA9EPYnj7zLsist HZJA== 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=kHj+b8RHvsTX7k50kt7WXWdFA+kgKCNEYLolpRgRrAo=; b=bB7HRIrU9T2CoIE1+xoov3MMSodhrnAtobgGi5eGWz1O98CyJlcpkvUjjAxkgq3vl0 8gQYN/ea1VXOj2BA81EzAGAkcgrCUCuGAHoFCDRZ7n1RQNS0EDMD4V1a+5ynZDM5zOlF HH9BkYBK3JqaM4DjtgL0W9axYnOazNJvmxlFCgp1anUsjrv+wNG8LZ3LB4/t5bPXpej7 891Ggtu8f2TW8JHTgsTcz2xsfIMwEADxQVbaW9Zs8uSKmhgRy+CUCr2Zyie73uxX6sT+ w0FzDYEvDqIpZUD+82IzZLsclHfyFX9thBnO8GrA6q31qUx4ejsYDD78Fx1sB70iot0o D5sA== X-Gm-Message-State: AGi0PuYU7PC31ECQ/Oc/egkJjZYiKXwIvGwVbqGU8eKp3EKNopsiAknX cf/0Piv5GdXriZbSSIEh5spDoumza6cZFcPWe3raFA== X-Google-Smtp-Source: APiQypKQEkOT4RpN18yf7F9t3SdjGRfh76j7tISx1PZ7r+9JVS1m5X7U25L7a77//Up7x8PSOzuiQK/OJZk+frl9R0E= X-Received: by 2002:a92:d0d:: with SMTP id 13mr2653930iln.170.1586267334922; Tue, 07 Apr 2020 06:48:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Tue, 7 Apr 2020 22:48:43 +0900 Message-ID: To: Owen DeLong Cc: Ron Bonica , Timothy Winters , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000005029005a2b3a5cc" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 13:49:17 -0000 --00000000000005029005a2b3a5cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 7, 2020 at 6:47 AM Owen DeLong wrote: > By recommending that lifetimes should be dynamically updated, this draft > will defeat devices that do #2. Based on past experience, a likely outcom= e > is that manufacturers will react by switching to #1 and dropping all RAs. > We should try to avoid making this problem worse with this draft. > > But if you don=E2=80=99t update the lifetimes, then you=E2=80=99re handin= g out PIOs that > contain a lifetime beyond the end of the IA_PD lease. > > Could we perhaps recommend sending out PIOs that are 1/4 or 1/3 of the > original IA_PD lease so long as the lease is renewed and then dynamically > counting down to 0 such that the PIO never contains a lifetime longer tha= n > the IA_PD validity? > > This should provide a best of both worlds=E2=80=A6 Until the IA_PD expire= s without > renewal, the PIO should contain a fixed lifetime, but in the (rare) case > where a prefix is expiring, we sacrifice some battery life to avoid a los= s > of connectivity. > Why can't we go even further and just suggest that the maximum lifetimes be capped to some reasonable value, such as a few hours or a day? --00000000000005029005a2b3a5cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 7, 2020 at 6:47 AM Owen DeLon= g <owen@delong.com> wrote:
=
By recommending that lifetimes should be d= ynamically updated, this draft will defeat devices that do #2. Based on pas= t experience, a likely outcome is that manufacturers will react by switchin= g to #1 and dropping all RAs. We should try to avoid making this problem wo= rse with this draft.
But if you don=E2=80=99t= update the lifetimes, then you=E2=80=99re handing out PIOs that contain a = lifetime beyond the end of the IA_PD lease.

Could = we perhaps recommend sending out PIOs that are 1/4 or 1/3 of the original I= A_PD lease so long as the lease is renewed and then dynamically counting do= wn to 0 such that the PIO never contains a lifetime longer than the IA_PD v= alidity?

This should provide a best of both worlds= =E2=80=A6 Until the IA_PD expires without renewal, the PIO should contain a= fixed lifetime, but in the (rare) case where a prefix is expiring, we sacr= ifice some battery life to avoid a loss of connectivity.

Why can't we go even further and just suggest= that the maximum lifetimes be capped to some reasonable value, such as a f= ew hours or a day?
--00000000000005029005a2b3a5cc-- From nobody Tue Apr 7 06:57:02 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19213A0A4F for ; Tue, 7 Apr 2020 06:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qacafe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TwhiHvkxu0a for ; Tue, 7 Apr 2020 06:56:59 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1259B3A0A47 for ; Tue, 7 Apr 2020 06:56:59 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id 31so4021968wre.5 for ; Tue, 07 Apr 2020 06:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tuhBh26c8SeuKvUVqADWeXy9/p5SzQ0lo2ODQ4jb4aY=; b=hOrZrfUkFlWWETKBZJBMt1w3jEn+6yCgN8Gxp4Na6lJnd+prUxqAu8F1j0E1TW4+/O PNLupMYVZcowdaJhDt9KksvPjZMjvkHYcGHtWWJHXT7vIVKWg0QfbKKIRj6HN3Yuy2Nf t8Vj18HY7qluJX9ejb4EwZiZ6FMsHzVBCNDnY= 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=tuhBh26c8SeuKvUVqADWeXy9/p5SzQ0lo2ODQ4jb4aY=; b=ba9cDfMleM20IgR3Zpx5DO9J3gyVhdsvaMBP7wbuUjgstqLhNbRLp+s4oPg5Iiu2xC YxovnHOhxyCF75GcWi2XsVjmiZCmTllQnDOo/d81xjL7hcJ2/WqV3R6NufY4rGgF5+xO PVQY5TAq4lGUSw7bPPrMFWg4QYApGkzqAFDxNTwQ5DqBfZdIrtibAj9P0VyXNNVFl/o1 T4HJA7a9EtBSzYyxpzdrw8LTQ6zsVMw70dgiqqv31jqAHvO6fyDoIg7QumCvhoG08IDL +Xyc9R0cQcvJ7P0TOWKT92cZnCBKGis7YuC6vQ3NscTOCwuwbHUrgGacPvuGrHfvHgmz G4MA== X-Gm-Message-State: AGi0PubuJdLB5mcABpcKWc4mbrj4cfL4UEZyqQ7OMlOL7mip/3f3spA2 IGPa4utSjYoEd+qJYMuf1cGUtL3UKnyryH3FiT+HhQ== X-Google-Smtp-Source: APiQypITF+OQCjS+iuNZBa8crn7/mYB4r0F+SyxCycGo8zgEfrAT0Sh50Fk9bOnqqlnZlNxqxCkLuuQ1DWq6zQwhfHQ= X-Received: by 2002:adf:fe87:: with SMTP id l7mr2804090wrr.377.1586267817622; Tue, 07 Apr 2020 06:56:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Timothy Winters Date: Tue, 7 Apr 2020 09:56:46 -0400 Message-ID: To: Lorenzo Colitti Cc: Owen DeLong , "v6ops@ietf.org" , Timothy Winters Content-Type: multipart/alternative; boundary="000000000000c9d61105a2b3c10e" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 13:57:01 -0000 --000000000000c9d61105a2b3c10e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 7, 2020 at 9:50 AM Lorenzo Colitti wrote: > On Tue, Apr 7, 2020 at 6:47 AM Owen DeLong wrote: > >> By recommending that lifetimes should be dynamically updated, this draft >> will defeat devices that do #2. Based on past experience, a likely outco= me >> is that manufacturers will react by switching to #1 and dropping all RAs= . >> We should try to avoid making this problem worse with this draft. >> >> But if you don=E2=80=99t update the lifetimes, then you=E2=80=99re handi= ng out PIOs that >> contain a lifetime beyond the end of the IA_PD lease. >> >> Could we perhaps recommend sending out PIOs that are 1/4 or 1/3 of the >> original IA_PD lease so long as the lease is renewed and then dynamicall= y >> counting down to 0 such that the PIO never contains a lifetime longer th= an >> the IA_PD validity? >> >> This should provide a best of both worlds=E2=80=A6 Until the IA_PD expir= es >> without renewal, the PIO should contain a fixed lifetime, but in the (ra= re) >> case where a prefix is expiring, we sacrifice some battery life to avoid= a >> loss of connectivity. >> > > Why can't we go even further and just suggest that the maximum lifetimes > be capped to some reasonable value, such as a few hours or a day? > I think this is what I think makes the most sense. Do operators think there is a reason to have the super long addresses? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000c9d61105a2b3c10e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 7, 2020 at 9:50 AM Lorenz= o Colitti <lorenzo=3D40go= ogle.com@dmarc.ietf.org> wrote:
On Tue, Apr 7, 202= 0 at 6:47 AM Owen DeLong <owen@delong.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
By recommending that lifetimes should = be dynamically updated, this draft will defeat devices that do #2. Based on= past experience, a likely outcome is that manufacturers will react by swit= ching to #1 and dropping all RAs. We should try to avoid making this proble= m worse with this draft.
But if you don=E2=80= =99t update the lifetimes, then you=E2=80=99re handing out PIOs that contai= n a lifetime beyond the end of the IA_PD lease.

Co= uld we perhaps recommend sending out PIOs that are 1/4 or 1/3 of the origin= al IA_PD lease so long as the lease is renewed and then dynamically countin= g down to 0 such that the PIO never contains a lifetime longer than the IA_= PD validity?

This should provide a best of both wo= rlds=E2=80=A6 Until the IA_PD expires without renewal, the PIO should conta= in a fixed lifetime, but in the (rare) case where a prefix is expiring, we = sacrifice some battery life to avoid a loss of connectivity.

Why can't we go even further and just sug= gest that the maximum lifetimes be capped to some reasonable value, such as= a few hours or a day?
I think this is w= hat I think makes the most=C2=A0sense.=C2=A0 Do operators think there is a = reason to have the super long addresses?
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000c9d61105a2b3c10e-- From nobody Tue Apr 7 06:59:46 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5E23A0A53 for ; Tue, 7 Apr 2020 06:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 FZ0dYCsmbo8S for ; Tue, 7 Apr 2020 06:59:43 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0AC3A0A50 for ; Tue, 7 Apr 2020 06:59:43 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79d:53aa:d30:5993:9b47:c769:f1e9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 43D0B4E11B13; Tue, 7 Apr 2020 13:59:43 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id C056431699FE; Tue, 7 Apr 2020 15:59:36 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Tue, 7 Apr 2020 15:59:36 +0200 Cc: Lorenzo Colitti , "v6ops@ietf.org" , Timothy Winters Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Timothy Winters X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 13:59:45 -0000 >> By recommending that lifetimes should be dynamically updated, this = draft will defeat devices that do #2. Based on past experience, a likely = outcome is that manufacturers will react by switching to #1 and dropping = all RAs. We should try to avoid making this problem worse with this = draft. > But if you don=E2=80=99t update the lifetimes, then you=E2=80=99re = handing out PIOs that contain a lifetime beyond the end of the IA_PD = lease. >=20 > Could we perhaps recommend sending out PIOs that are 1/4 or 1/3 of the = original IA_PD lease so long as the lease is renewed and then = dynamically counting down to 0 such that the PIO never contains a = lifetime longer than the IA_PD validity? >=20 > This should provide a best of both worlds=E2=80=A6 Until the IA_PD = expires without renewal, the PIO should contain a fixed lifetime, but in = the (rare) case where a prefix is expiring, we sacrifice some battery = life to avoid a loss of connectivity. >=20 > Why can't we go even further and just suggest that the maximum = lifetimes be capped to some reasonable value, such as a few hours or a = day? > I think this is what I think makes the most sense. Do operators think = there is a reason to have the super long addresses? Like cap them to 64 bit you mean? ;-) Users think there are many reasons to have long lived addresses. I think this idea of trying to make address lifetimes act as dead timers = for reachability severely broken. Routing !=3D Addressing. Cheers, Ole= From nobody Tue Apr 7 07:05:59 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571483A0A89 for ; Tue, 7 Apr 2020 07:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 6uWwo8K10Jm9 for ; Tue, 7 Apr 2020 07:05:56 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BB03A0A88 for ; Tue, 7 Apr 2020 07:05:55 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id i19so1451747ioh.12 for ; Tue, 07 Apr 2020 07:05:55 -0700 (PDT) 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=Wk4kPowgT9i8BvwwGHBo0m9lUDVjDV9vidYMm5qJrFM=; b=cd+0RGikwbH1V8+w0+VebM47+BFuzYVBiQdfTmIlxbqbE79TvLIQO/KmHmuep+j67j bnI1MOmVOPgckzFxYYdprDsF5xBoBAuwnGCWbemlpyaC+38TQufn2mnqoanXwmila73b H9Z/VJaI4/+NoybVR+gEVJkLLw9n22++jBs3mQnBTVMmhBQqZGmP2rfPJ4RwQy8eL3kI Vb9YefhDhQloqBAg3ThxAXXIZbRSBYRhQaOojx1rSUV4FN1imo1fwRGN+QZTqm3Q4JXr nyj50IlK6CCHa5DS8boi12El1+rJoMgDmFdY5KBCY+urKTKCHTBbQdDySTbV4hmi3PO7 4kfw== 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=Wk4kPowgT9i8BvwwGHBo0m9lUDVjDV9vidYMm5qJrFM=; b=hY7m+pTYW8FajuIzau/BhZ2bx2aaWkf01o3WvwUhjQqXCS82vezmqvsoeXXum8Ng01 cWQGGMYQqjeeIb1qURVdTUV2uZE81aIEUO0UsHPD+TMcTkBsWKtZS+UHXQYdGBOfC9RN KFB4bsYQDr37qsqgPUegRMMTC5bIyUanY2Oo7SZ7Kz1+Mv5SlbNmXeU3vPvafrxVUJNd ZhnidfTuFPDboiBrZWFMKSIWN8UIFh2VG9HcttewPJD8MTaxP9eux5F7oLfC2xDm3y2E X5vTJBnqup9Vp0tY6F6HovibvvqA1eYSoPCjBUZEKR7y2xc6eVqJT9X5Nt3DhRY5vK/R Iovg== X-Gm-Message-State: AGi0Pub82K/RHQ9sFpptuyvDdh6zfZfFm2kt8pgKfkWmIgWY/yL7MTYp xCnYJTD6bvm5fc5FYxf8cNJ+dwiq8K237zIXanBGDMycCjM= X-Google-Smtp-Source: APiQypIhPP4ijxnGCoJO6ZRxkjWRXK/dVAxeOS5zcDa3tB3EE97okRWuU+DkEIJLQtHAq8cIx/aA7I+mGlCTYYW8qSQ= X-Received: by 2002:a05:6602:164b:: with SMTP id y11mr2308407iow.3.1586268354612; Tue, 07 Apr 2020 07:05:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Tue, 7 Apr 2020 23:05:41 +0900 Message-ID: To: Ole Troan Cc: Timothy Winters , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cc4d3a05a2b3e113" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 14:05:57 -0000 --000000000000cc4d3a05a2b3e113 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 7, 2020 at 10:59 PM wrote: > > Why can't we go even further and just suggest that the maximum lifetimes > be capped to some reasonable value, such as a few hours or a day? > > I think this is what I think makes the most sense. Do operators think > there is a reason to have the super long addresses? > > Like cap them to 64 bit you mean? ;-) > > Users think there are many reasons to have long lived addresses. > I think this idea of trying to make address lifetimes act as dead timers > for reachability severely broken. > > Routing != Addressing. > To be clear: I'm not suggesting the maximum lifetime be capped within the router. I'm suggesting the maximum lifetime be capped *in the RA*. In other words, if an ISP announces a lifetime of 100 years, the RA would still contain something like 9000 seconds, 86400 seconds, or whatever value we pick. So yes - if the router went away for more than 9000/86400/... seconds the addresses would become invalid. Rationale: I think an address isn't very useful if you can't use it to receive packets. (I know you don't agree with me on this, but others might.) --000000000000cc4d3a05a2b3e113 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 7, 2020 at 10:59 PM <otroan@employees.org> wrote:
> Why can't we go even further and just sug= gest that the maximum lifetimes be capped to some reasonable value, such as= a few hours or a day?
> I think this is what I think makes the most sense.=C2=A0 Do operators = think there is a reason to have the super long addresses?

Like cap them to 64 bit you mean? ;-)

Users think there are many reasons to have long lived addresses.
I think this idea of trying to make address lifetimes act as dead timers fo= r reachability severely broken.

Routing !=3D Addressing.

--000000000000cc4d3a05a2b3e113-- From nobody Tue Apr 7 07:11:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8B93A0AB6 for ; Tue, 7 Apr 2020 07:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=aX+kN3C7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=a8M95l7M Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVmhIGFwpYi2 for ; Tue, 7 Apr 2020 07:11:47 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5502D3A0AB1 for ; Tue, 7 Apr 2020 07:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13006; q=dns/txt; s=iport; t=1586268707; x=1587478307; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QM25Bk1OmE0Y6+WWcPjiqqkjE5suWIpsdifBk63seSc=; b=aX+kN3C7x/wDAZ5OrDgqAM2uLC4ARGMv/LWiwt1rDxIBbdM2NACQbUtC AeMDP+tmZJ1bSep1hvPkqKqPcrbvn856kL6LwbY+u0WaaXTAFlwi+rjoZ tWweBk0kNWJsCzfk1YvebKtIM0ctalMOZmIMmxOMh3hHmrBXgBuHquXBi w=; IronPort-PHdr: =?us-ascii?q?9a23=3AM/FqgResS4ze01hDDsp04iRklGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwKUD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFl?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeDtaz4SF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAACpiYxe/4ENJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBZwYBAQELAYEkL1AFbFggBAsqCoQSg0UDhFmGDYJfk0C?= =?us-ascii?q?EYYEugSQDVAoBAQEMAQEtAgQBAYREAheBbiQ0CQ4CAwEBCwEBBQEBAQIBBQR?= =?us-ascii?q?thVYMhXABAQEBAgESEQoTAQE3AQQLAgEIEQQBAQEnAwICAjAUCQgCBAENBQg?= =?us-ascii?q?agwWBfk0DDiABpSACgTmIYnWBMoJ/AQEFhT4Ygg0JgTgBjDIaggCBVIJNPoR?= =?us-ascii?q?QNIJcMoIskQuGBZogCoI9l02cB4tDg3icKAIEAgQFAg4BAQWBUjmBV3AVgyR?= =?us-ascii?q?QGA1YkEqDc4pVdIEpjRsBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.72,354,1580774400"; d="scan'208,217";a="474991016" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Apr 2020 14:11:46 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 037EBkQP004865 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Apr 2020 14:11:46 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Apr 2020 09:11:46 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Apr 2020 09:11:45 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 7 Apr 2020 10:11:45 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jRpCA2wwBvCg3O3dsIMhgBY7uFys8BwXk31RO2Appnt6CT1o4XbGRik+32YG6i0Crse4V21CiP+eCJ+yZ8ht1YHt6g0Stqzimv2U8KIqnBllQ8FF217Vw+FrlcQIeFTMVZiWbFWX0NRRdNHRVoiR/Dt2vpdwiwphxJzxCyHYP/v6ebZeu4SR+IdzaWT+4CaRTnDqImr035wMRnZ4lvUdjMX2WNs01p0kcV8G4+zeIzM1Szw/uYGY5GamIO/3JUsvAsQVQPW4byXUJa6BbNZjchagHKuMkTcvsNDATdWWQJ1x4bagWwq9H9FybpDbXCE6lwwjlLguowWYdsTIGeNFzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QM25Bk1OmE0Y6+WWcPjiqqkjE5suWIpsdifBk63seSc=; b=n3EA7oLdu6c9cIad6EXEfc3VcBP1hkLst7KbY7VCv/mcxV4iV3neVS5mYkz0CpsTn8zwUebpHRODAtIZedq2vfnrPtB+F3bJFdKUiMFVmC/1a6TbNjDiIW0kfjYZ3Qq3pU6RuIPn85i0N60M3GYG8X2iN3KLs26E9rSNNLwDqb2cKzWzUk2tcXemBj5G08qQWxhmTLcWBJoDc0x2+o7bfqOeXGyQcqJYUZ9YUCIcQayx8aqqcT9NoZ4jL7aIAGhhgL2+rgdbmMEqDCN863c1uny1dA6Hbuy6faLtseLp7nufGDj5eL0irXEUA0ZKTuBaYcBvDiXsZunuKyZ1A+p3hQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QM25Bk1OmE0Y6+WWcPjiqqkjE5suWIpsdifBk63seSc=; b=a8M95l7MSxx+56ih32RGykrdpl2zvZXLXDs0nK5SUFykRvKalMhT3Kvo3fv9eufs4xv5r7X5JyXu32QxWpLR1wgzStDuR+xMjurt+agmpL2m9PGzY99wC5kxpKsfqmzt4jtcdC0NDAP8PPetu2FE3DLdb2DktzH+6pDiNKIbv2g= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2724.namprd11.prod.outlook.com (2603:10b6:406:b3::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Tue, 7 Apr 2020 14:11:42 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Tue, 7 Apr 2020 14:11:42 +0000 From: "Bernie Volz (volz)" To: Lorenzo Colitti , Ole Troan CC: "v6ops@ietf.org" Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdYGqnrRGOoD4f0yRz2uh9FnYboxrQFa48mAABGxD4AAIZyHgAAAR/kAAAAZVQAAADZjgAAAEa8A Date: Tue, 7 Apr 2020 14:11:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e34fe22c-24ce-4023-2f5f-08d7dafd992e x-ms-traffictypediagnostic: BN7PR11MB2724: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(396003)(136003)(39860400002)(376002)(366004)(316002)(4326008)(53546011)(33656002)(55016002)(81166006)(81156014)(8676002)(66556008)(76116006)(5660300002)(64756008)(66446008)(6506007)(86362001)(9686003)(8936002)(186003)(110136005)(2906002)(66574012)(7696005)(66946007)(52536014)(66476007)(26005)(71200400001)(478600001); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lBYUjY58n6L1QXlmuKhtwUwF3eHJOLcMa+n//+86jbFTnsEFy78BjMrh2Mr6fGfKoSNmkA/AdAfCxoyMGpvDK0B0+7nyfeEMPXFGpNJxeBRh45yBXfySU8LePoFjGBivXeDcXy7xbDbdEikrSFb163bOWcEkXDAd2gt9Q7Ie6cw+hxjRgzg9J2Fp9SdIJGME4Cobtpvj+uZPL6wj/ZqApAtu8XFLfPXdP+V9gDZWzz9GFyJOFrGsy6wljVdeKgjqwf0t6igLtBJGG/5YbiA5ItENPTAAHltwoGDFCy0qpkLt0nn3+9JuB8Vd8Rs6yhOgAC6I6ZK05YSNoRgdtaVwurOEMGnMDKQNpQsUNsi3ErfMFuWONNRe7wROwMuXx9VKlNJN54Djt9DpzrDIGoEGMY7pFmmyV7TD813t+Kb7WQMwkv7cgNpcxLzOUOKdBWwS x-ms-exchange-antispam-messagedata: AhrG7FQuaJpDRuUKkI8ttLnDq/sqL7YpizjairauA2LGLlg7LHjGga4sEXTq47X3b9OZH92PBF3Mhhtq26S8qi1VBv4t7rYX2w/fMIXaS00ruRu3wx03U7aOh0hugstorYhIPOGs6H6e4KXT0oVzsw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB254708D23F5533CB0F820200CFC30BN7PR11MB2547namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e34fe22c-24ce-4023-2f5f-08d7dafd992e X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2020 14:11:42.6866 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uDDr9879mK2o48yBmRUY8Xk8ZQ+ESnXSKM9v8aOyLrGICBplmsdEvPmgo8LT15o2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2724 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 14:11:50 -0000 --_000_BN7PR11MB254708D23F5533CB0F820200CFC30BN7PR11MB2547namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WXVwLCB0aGF0IGlzIGV4YWN0bHkgd2hhdCBJIHRob3VnaHQgd2FzIGJlaW5nIHN1Z2dlc3RlZCBh bmQgSSB0aGluayBtYWtlcyBnb29kIHNlbnNlLg0KDQoNClRoZSBvbmx5IGhhcm0gdGhhdCB1c2lu ZyBjYXBwZWQgbGlmZXRpbWVzIChpbnN0ZWFkIG9mIHRoZSBmdWxsIFBEIGxpZmV0aW1lKSBpcyB0 aGF0IGlmIHRoZSBDUEUgZGV2aWNlIGl0c2VsZiBnb2VzIGRvd24sIHRoZSBHTEFzIG1heSBiZSBs b3N0IHByZW1hdHVyZWx5LiBJZiB0aGUgQ1BFIGlzIG9wZXJhdGluZywgaXQgd2lsbCBjb250aW51 ZSB0byBzZW5kIG91dCBSQXMgKHVudGlsIHRoZSBsaWZldGltZSBleHBpcmVzKS4NCg0KDQoNCkFu ZCB3aXRoIGNhcHMgc3VmZmljaWVudGx5IGhpZ2gsIFRDUCBjb25uZWN0aW9ucyB3aWxsIGFsbW9z dCBjZXJ0YWlubHkgaGF2ZSB0aW1lZCBvdXQgYnkgdGhlIHRpbWUgdGhlIGNhcHBlZCBsaWZldGlt ZXMgZXhwaXJlcy4NCg0KDQogICogICBCZXJuaWUNCg0KRnJvbTogdjZvcHMgPHY2b3BzLWJvdW5j ZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBMb3JlbnpvIENvbGl0dGkNClNlbnQ6IFR1ZXNkYXks IEFwcmlsIDcsIDIwMjAgMTA6MDYgQU0NClRvOiBPbGUgVHJvYW4gPG90cm9hbkBlbXBsb3llZXMu b3JnPg0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBXRyBMYXN0IENh bGwgb24gZHJhZnQtaWV0Zi12Nm9wcy1jcGUtc2xhYWMtcmVudW0NCg0KT24gVHVlLCBBcHIgNywg MjAyMCBhdCAxMDo1OSBQTSA8b3Ryb2FuQGVtcGxveWVlcy5vcmc8bWFpbHRvOm90cm9hbkBlbXBs b3llZXMub3JnPj4gd3JvdGU6DQo+IFdoeSBjYW4ndCB3ZSBnbyBldmVuIGZ1cnRoZXIgYW5kIGp1 c3Qgc3VnZ2VzdCB0aGF0IHRoZSBtYXhpbXVtIGxpZmV0aW1lcyBiZSBjYXBwZWQgdG8gc29tZSBy ZWFzb25hYmxlIHZhbHVlLCBzdWNoIGFzIGEgZmV3IGhvdXJzIG9yIGEgZGF5Pw0KPiBJIHRoaW5r IHRoaXMgaXMgd2hhdCBJIHRoaW5rIG1ha2VzIHRoZSBtb3N0IHNlbnNlLiAgRG8gb3BlcmF0b3Jz IHRoaW5rIHRoZXJlIGlzIGEgcmVhc29uIHRvIGhhdmUgdGhlIHN1cGVyIGxvbmcgYWRkcmVzc2Vz Pw0KDQpMaWtlIGNhcCB0aGVtIHRvIDY0IGJpdCB5b3UgbWVhbj8gOy0pDQoNClVzZXJzIHRoaW5r IHRoZXJlIGFyZSBtYW55IHJlYXNvbnMgdG8gaGF2ZSBsb25nIGxpdmVkIGFkZHJlc3Nlcy4NCkkg dGhpbmsgdGhpcyBpZGVhIG9mIHRyeWluZyB0byBtYWtlIGFkZHJlc3MgbGlmZXRpbWVzIGFjdCBh cyBkZWFkIHRpbWVycyBmb3IgcmVhY2hhYmlsaXR5IHNldmVyZWx5IGJyb2tlbi4NCg0KUm91dGlu ZyAhPSBBZGRyZXNzaW5nLg0KDQpUbyBiZSBjbGVhcjogSSdtIG5vdCBzdWdnZXN0aW5nIHRoZSBt YXhpbXVtIGxpZmV0aW1lIGJlIGNhcHBlZCB3aXRoaW4gdGhlIHJvdXRlci4gSSdtIHN1Z2dlc3Rp bmcgdGhlIG1heGltdW0gbGlmZXRpbWUgYmUgY2FwcGVkICppbiB0aGUgUkEqLiBJbiBvdGhlciB3 b3JkcywgaWYgYW4gSVNQIGFubm91bmNlcyBhIGxpZmV0aW1lIG9mIDEwMCB5ZWFycywgdGhlIFJB IHdvdWxkIHN0aWxsIGNvbnRhaW4gc29tZXRoaW5nIGxpa2UgOTAwMCBzZWNvbmRzLCA4NjQwMCBz ZWNvbmRzLCBvciB3aGF0ZXZlciB2YWx1ZSB3ZSBwaWNrLiBTbyB5ZXMgLSBpZiB0aGUgcm91dGVy IHdlbnQgYXdheSBmb3IgbW9yZSB0aGFuIDkwMDAvODY0MDAvLi4uIHNlY29uZHMgdGhlIGFkZHJl c3NlcyB3b3VsZCBiZWNvbWUgaW52YWxpZC4gUmF0aW9uYWxlOiBJIHRoaW5rIGFuIGFkZHJlc3Mg aXNuJ3QgdmVyeSB1c2VmdWwgaWYgeW91IGNhbid0IHVzZSBpdCB0byByZWNlaXZlIHBhY2tldHMu IChJIGtub3cgeW91IGRvbid0IGFncmVlIHdpdGggbWUgb24gdGhpcywgYnV0IG90aGVycyBtaWdo dC4pDQo= --_000_BN7PR11MB254708D23F5533CB0F820200CFC30BN7PR11MB2547namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxh aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTc2ODAzNDYz ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExODA2 NTAzOTIgODMwMjYzMjI2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPll1cCwgdGhhdCBpcyBleGFjdGx5IHdoYXQgSSB0aG91Z2h0IHdhcyBiZWluZyBzdWdn ZXN0ZWQgYW5kIEkgdGhpbmsgbWFrZXMgZ29vZCBzZW5zZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+VGhlIG9ubHkgaGFybSB0aGF0IHVzaW5nIGNhcHBlZCBsaWZldGltZXMgKGluc3RlYWQg b2YgdGhlIGZ1bGwgUEQgbGlmZXRpbWUpIGlzIHRoYXQgaWYgdGhlIENQRSBkZXZpY2UgaXRzZWxm IGdvZXMgZG93biwgdGhlIEdMQXMgbWF5IGJlIGxvc3QgcHJlbWF0dXJlbHkuIElmIHRoZSBDUEUg aXMgb3BlcmF0aW5nLCBpdCB3aWxsIGNvbnRpbnVlIHRvIHNlbmQgb3V0IFJBcyAodW50aWwgdGhl IGxpZmV0aW1lIGV4cGlyZXMpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BbmQgd2l0 aCBjYXBzIHN1ZmZpY2llbnRseSBoaWdoLCBUQ1AgY29ubmVjdGlvbnMgd2lsbCBhbG1vc3QgY2Vy dGFpbmx5IGhhdmUgdGltZWQgb3V0IGJ5IHRoZSB0aW1lIHRoZSBjYXBwZWQgbGlmZXRpbWVzIGV4 cGlyZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj5CZXJuaWU8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IHY2b3BzICZsdDt2Nm9wcy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYg T2YgPC9iPg0KTG9yZW56byBDb2xpdHRpPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmls IDcsIDIwMjAgMTA6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IE9sZSBUcm9hbiAmbHQ7b3Ryb2FuQGVt cGxveWVlcy5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB2Nm9wc0BpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBXRyBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi12Nm9wcy1j cGUtc2xhYWMtcmVudW08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU dWUsIEFwciA3LCAyMDIwIGF0IDEwOjU5IFBNICZsdDs8YSBocmVmPSJtYWlsdG86b3Ryb2FuQGVt cGxveWVlcy5vcmciIHRhcmdldD0iX2JsYW5rIj5vdHJvYW5AZW1wbG95ZWVzLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDsgV2h5IGNhbid0IHdlIGdvIGV2ZW4gZnVydGhlciBhbmQganVz dCBzdWdnZXN0IHRoYXQgdGhlIG1heGltdW0gbGlmZXRpbWVzIGJlIGNhcHBlZCB0byBzb21lIHJl YXNvbmFibGUgdmFsdWUsIHN1Y2ggYXMgYSBmZXcgaG91cnMgb3IgYSBkYXk/PGJyPg0KJmd0OyBJ IHRoaW5rIHRoaXMgaXMgd2hhdCBJIHRoaW5rIG1ha2VzIHRoZSBtb3N0IHNlbnNlLiZuYnNwOyBE byBvcGVyYXRvcnMgdGhpbmsgdGhlcmUgaXMgYSByZWFzb24gdG8gaGF2ZSB0aGUgc3VwZXIgbG9u ZyBhZGRyZXNzZXM/PGJyPg0KPGJyPg0KTGlrZSBjYXAgdGhlbSB0byA2NCBiaXQgeW91IG1lYW4/ IDstKTxicj4NCjxicj4NClVzZXJzIHRoaW5rIHRoZXJlIGFyZSBtYW55IHJlYXNvbnMgdG8gaGF2 ZSBsb25nIGxpdmVkIGFkZHJlc3Nlcy48YnI+DQpJIHRoaW5rIHRoaXMgaWRlYSBvZiB0cnlpbmcg dG8gbWFrZSBhZGRyZXNzIGxpZmV0aW1lcyBhY3QgYXMgZGVhZCB0aW1lcnMgZm9yIHJlYWNoYWJp bGl0eSBzZXZlcmVseSBicm9rZW4uPGJyPg0KPGJyPg0KUm91dGluZyAhPSBBZGRyZXNzaW5nLjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VG8gYmUgY2xlYXI6IEknbSBub3Qgc3VnZ2VzdGluZyB0aGUgbWF4aW11bSBsaWZldGltZSBi ZSBjYXBwZWQgd2l0aGluIHRoZSByb3V0ZXIuIEknbSBzdWdnZXN0aW5nIHRoZSBtYXhpbXVtIGxp ZmV0aW1lIGJlIGNhcHBlZCAqaW4gdGhlIFJBKi4gSW4gb3RoZXIgd29yZHMsIGlmIGFuIElTUCBh bm5vdW5jZXMgYSBsaWZldGltZSBvZiAxMDAgeWVhcnMsIHRoZSBSQSB3b3VsZCBzdGlsbCBjb250 YWluIHNvbWV0aGluZw0KIGxpa2UgOTAwMCBzZWNvbmRzLCA4NjQwMCBzZWNvbmRzLCBvciB3aGF0 ZXZlciB2YWx1ZSB3ZSBwaWNrLiBTbyB5ZXMgLSBpZiB0aGUgcm91dGVyIHdlbnQgYXdheSBmb3Ig bW9yZSB0aGFuIDkwMDAvODY0MDAvLi4uIHNlY29uZHMgdGhlIGFkZHJlc3NlcyB3b3VsZCBiZWNv bWUgaW52YWxpZC4gUmF0aW9uYWxlOiBJIHRoaW5rIGFuIGFkZHJlc3MgaXNuJ3QgdmVyeSB1c2Vm dWwgaWYgeW91IGNhbid0IHVzZSBpdCB0byByZWNlaXZlIHBhY2tldHMuIChJDQoga25vdyB5b3Ug ZG9uJ3QgYWdyZWUgd2l0aCBtZSBvbiB0aGlzLCBidXQgb3RoZXJzIG1pZ2h0Lik8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN7PR11MB254708D23F5533CB0F820200CFC30BN7PR11MB2547namp_-- From nobody Tue Apr 7 07:13:48 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B109B3A0A97 for ; Tue, 7 Apr 2020 07:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 1lclSVHXvivc for ; Tue, 7 Apr 2020 07:13:46 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0193A0AB1 for ; Tue, 7 Apr 2020 07:13:46 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id f20so2718342qtq.6 for ; Tue, 07 Apr 2020 07:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AwKpthITDHD7UqlwjyL/4WgQcImG9JGHtB4RSS175bs=; b=UPJr6X0oIEDGDdhhrvNHPRmSSLQVvBC9rbWwX8Hyfh1fOCDaBKaXYCnlpz8EtWth+D zO6wVVmYTm2sj3Hl6ns5u+ZtFMZ3gkhOk/mrH2j6bWLSDx/CgMeCNHxBburYT6Lv85HD RsGqCf1NUaYnH2WnaR0TKIG4Pf221XQKLWxTm+WJ1s3WvI4hUBMgfvzjxTEG5DK7TaH6 JujzH9+NHzQgO0GYWJLJMDta4qMp2Iw3+2MypMh053gND7wfGCCQOJa3qNtxQgA6M29s 0O9w95Hvu0Z8CUWyDLtj6lOYFPSVXm7G0CYw8JjskziNhkLnLuR8l9tAHelS6GZBGUEX 7KbA== 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=AwKpthITDHD7UqlwjyL/4WgQcImG9JGHtB4RSS175bs=; b=hCYc7Zmyi0rWZgV3YO6fPT+ca3eBKeJdmc40PNhpZuXdwqIQ169FGI0Nw5Pud7xJe8 cC6IVE9kUY7mLrItigKuDNJGGnvtjMnetBZyHnzPhH4AIFI6zWiWnDek0LXB4Kn1hvdx Skw8GSoEtsfHB89KFuceDvwTauudyxnxibgBPSumqYEKypnJD0kiIjzlg01cTIK+qE4T 8XjAPjnefuypEFLt1+GIk3B8WHScmm1eeY2kjIvPCerzXp39R1xWvx351aaYrVucalRb 8Sh+llwh00xab7ADH+4Z2nd3nT6DvwsEp0deWzNO0vu7W7ar5PTKwidLtXfT/dWaGD3W Me0A== X-Gm-Message-State: AGi0PuYu/V876ChoFuIhAPXPzIWPVsA8QD1r5c2ohy+/gzaRM2rNOlJP K/oo9hKJsNOmISb7ovAnj8frRA== X-Google-Smtp-Source: APiQypJEYo68WZe6iBX/uHn20r7sfkoU8nRd/vDhq9UoZe9azbiYNitbmNJKsQoONwrScSo3gbK6aQ== X-Received: by 2002:ac8:7641:: with SMTP id i1mr2276395qtr.289.1586268825035; Tue, 07 Apr 2020 07:13:45 -0700 (PDT) Received: from [192.168.1.241] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id w30sm17944884qtw.21.2020.04.07.07.13.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2020 07:13:44 -0700 (PDT) From: Ted Lemon Message-Id: <14E3E429-B9C4-45F0-AA06-450580843EB2@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A68A7554-3CEA-4C94-88C6-C039D84F34A8" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.6\)) Date: Tue, 7 Apr 2020 10:13:42 -0400 In-Reply-To: Cc: Timothy Winters , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters To: otroan@employees.org References: X-Mailer: Apple Mail (2.3622.0.6) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 14:13:48 -0000 --Apple-Mail=_A68A7554-3CEA-4C94-88C6-C039D84F34A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 7, 2020, at 9:59 AM, otroan@employees.org wrote: > I think this idea of trying to make address lifetimes act as dead = timers for reachability severely broken. I think that in principle this is true, but I=E2=80=99m not sure that it = follows in practice. What should we be doing instead? Or was this just = a miscommunication, per Lorenzo=E2=80=99s clarifying message? My experience with this tends to make me want to agree with Lorenzo. = The longer a PIO prefix lifetime is, the longer things are broken when = the router stops advertising the prefix without deprecating it. OTOH, = it=E2=80=99s _always_ going to be too long, so as you say, we really = want a better way to detect that we have a problem. Right now if one = device remembers a stale on-link prefix that another device has not = seen, the first device may choose that stale prefix during source = address selection, and of course since the second device doesn=E2=80=99t = see it as on-link, this will fail. How do we quickly detect this failure? --Apple-Mail=_A68A7554-3CEA-4C94-88C6-C039D84F34A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Apr 7, 2020, at 9:59 AM, otroan@employees.org wrote:
I think this idea of trying to make address lifetimes act as = dead timers for reachability severely = broken.

I = think that in principle this is true, but I=E2=80=99m not sure that it = follows in practice.  What should we be doing instead?  Or was = this just a miscommunication, per Lorenzo=E2=80=99s clarifying = message?

My = experience with this tends to make me want to agree with Lorenzo. =  The longer a PIO prefix lifetime is, the longer things are broken = when the router stops advertising the prefix without deprecating it. =  OTOH, it=E2=80=99s _always_ going to be too long, so as you say, = we really want a better way to detect that we have a problem. =  Right now if one device remembers a stale on-link prefix that = another device has not seen, the first device may choose that stale = prefix during source address selection, and of course since the second = device doesn=E2=80=99t see it as on-link, this will fail.

How do we quickly detect = this failure?

= --Apple-Mail=_A68A7554-3CEA-4C94-88C6-C039D84F34A8-- From nobody Tue Apr 7 07:17:41 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9B23A0AD4 for ; Tue, 7 Apr 2020 07:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WGk55J8c; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ojVq+OVf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy9Dr302q6B6 for ; Tue, 7 Apr 2020 07:17:37 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E504C3A0ACF for ; Tue, 7 Apr 2020 07:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20154; q=dns/txt; s=iport; t=1586269056; x=1587478656; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=P8wxuFAbxBR6bh+IpMW6xiVrTqH0ocPC9n8HiLVx0Wg=; b=WGk55J8cJpQUQlDyo1EN55Nq6p/c+vw8TMuA/agAgBvrsH0v7DN5kZpl f/WNnnUsCH9V1mXdd20nlq6RzyOwniNeq6jinBBG7Vf7Zr/EtcwfcO56y nuxBXjdGhnGsl5jM+sBa+xbqN/NEvxs04em5D8xv/kCMIihHSeeW4J/Vt o=; IronPort-PHdr: =?us-ascii?q?9a23=3AuZzfRxCyrzyJ1tL+5ZbmUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qgw3kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMdRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFP8KOzCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAABBi4xe/40NJK1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFoBAEBAQELAYEkL1AFbFggBAsqCoQSg0UDima?= =?us-ascii?q?CX5NAhGGBLoEkA1QKAQEBDAEBLQIEAQGERAIXgW4kNQgOAgMBAQsBAQUBAQE?= =?us-ascii?q?CAQUEbYVWDIVwAQEBAQIBEhEKEwEBNwEECwIBCBEEAQEBJwMCAgIwFAkIAgQ?= =?us-ascii?q?BDQUIGoMFgX5NAw4gAaUfAoE5iGJ1gTKCfwEBBYU+GIINCYE4AYwyGoIAgVS?= =?us-ascii?q?CTT6CZwSBZTSCXDKCLJELhgWaIAqCPZdNnAeLQ4N4nCgCBAIEBQIOAQEFgVM?= =?us-ascii?q?BN4FXcBWDJFAYDViQSoNzilV0AoEnjRsBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.72,354,1580774400"; d="scan'208,217";a="485353938" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Apr 2020 14:17:36 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 037EHZ4k010989 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Apr 2020 14:17:35 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Apr 2020 09:17:35 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Apr 2020 10:17:34 -0400 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 7 Apr 2020 09:17:34 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gq6DtWriXrTeo01ZRXxZq+MJV/9eWbQB3nBPJx/ZGao7na7BMuhHeGy1UDJvYraZRNE/jbqrwkw1NPK7758o5WQO66CNBHWXym6DjDzRO5yARBhoKc7dI0rylyBMt0C0Y6t+h1aUk7+zdWl/Tot1CUa7T2EaCbN6AR9CsgcNIcCP53BHi5V2ykek8rAmqfYRxXYo50aNSd5yEeqRRrDkCjBgIYhJnlEqqHjyDCpfyertsPLiOtMDZvc/8NMXRYrn2xOY1+IKQLSDH0FviinUyL+FVnd4mDml3jXEjhd6fWZUgI1/1+j5239InJScKJklVmqd/w2kgY/PYV03ia6edw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P8wxuFAbxBR6bh+IpMW6xiVrTqH0ocPC9n8HiLVx0Wg=; b=ULT2GQK1ZKte/6kS6Lw09sQp9GHX6wOflr6NgvniNnQb8/fzg1bjTpJiLjBzLk8sIfQ9h/yOyg5JQkJx2Asm/W5BpnNPCHMroDZDxQIaDwUNTWlAyVUSAgqbOSxgbOX26Iwe3orVw//GmyzewrJd+RkqUC7kBK5giEeWDwLM+qQ9Q1kcRlShMKZWHXRdcakM81MuSMUuPhMc5ZB9fjcXNZvMTJ0mtPdXpxpplqe4vovcM61ziNr5X58iszYMPGQHUo1TxGx7txnqIxLxRkmRtmjwNWDpJWmQKh6jK4yCqrE4NOJshJIvgka2gqDYUUHIQsoRcKv9G4eqDbE5bVrNCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P8wxuFAbxBR6bh+IpMW6xiVrTqH0ocPC9n8HiLVx0Wg=; b=ojVq+OVfae0aACNnQhxVGXsnD/0/WarbJ9sChf5rZMJMYX65jKBNHivUJMYRPOy3Rb1G1PkyP2O4N0cmAcqfBtc8Xd12AJk/Z/bUXfA021uoXxtEN9cxiDDaNS5WA9RY1AMM21moRnbC95Reipas7p2sC4dyBMxcnu4YTfWkapY= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2737.namprd11.prod.outlook.com (2603:10b6:406:b0::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Tue, 7 Apr 2020 14:17:33 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Tue, 7 Apr 2020 14:17:33 +0000 From: "Bernie Volz (volz)" To: Lorenzo Colitti , Ole Troan CC: "v6ops@ietf.org" Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdYGqnrRGOoD4f0yRz2uh9FnYboxrQFa48mAABGxD4AAIZyHgAAAR/kAAAAZVQAAADZjgAAAEa8AAABRWVA= Date: Tue, 7 Apr 2020 14:17:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 77b5c7dc-9740-4057-d91e-08d7dafe6a3d x-ms-traffictypediagnostic: BN7PR11MB2737: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(136003)(396003)(366004)(376002)(39860400002)(5660300002)(76116006)(478600001)(86362001)(6506007)(186003)(66556008)(53546011)(7696005)(66446008)(66476007)(2906002)(64756008)(33656002)(66946007)(55016002)(2940100002)(26005)(9686003)(4326008)(66574012)(81166006)(52536014)(8936002)(316002)(81156014)(110136005)(8676002)(71200400001); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 07rMx2oVzS0CxHpazHAna0F97RMpmcCBEgOsyf8PcsBxsLCQaRpjI4wtWl0680ClSWUV99H5SrQxRfHrJl059/pCxVTv9FDABg9lqXZf6HgK3j71THUoUQbIuV0RiiLUMpX6DnGb05JOv6ZlVENRWvFRvzLdGXOiBaOmMYKuJFh+f/bbGxalp8MptAlkDlZ+ulbU5GXkHgPRF4NCSmVtC4PLFUHYYxVWRyqhDSNl6yCfdXhk7MP6eYp+UesbQnMWVuXXaNHHC7lFD85LH3AAc267Yg/c/7kiH448+V8OJj7ISIF4va0+x+mweG0UQdMOjwl9mSdZkxb74f8GHzyhdLWjnYFwM4TCF7TR/JfActis9E4RnNmNDY4i3yQ0zuwSFbon/76w0u09Q/W/aBy0wwOmWeAZv9IiJZi3Bx56H6MAG89YsqhAwHd9FMWs2pYo x-ms-exchange-antispam-messagedata: FQJXG/MnaxnQGRHI0pNepvnjWccJ2GSL72Z3tJiGXNFgkBOdpq4YJXV2WXG0ggSIEjX2Mef27tFDopo+LWZucIzjU32Zj+084T7OdkkP+XQyQZsPgBlSlU+v7CQed/mzg1EzE0RXT+KqxeCHXJY53g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2547B5916BD602946FF64906CFC30BN7PR11MB2547namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 77b5c7dc-9740-4057-d91e-08d7dafe6a3d X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2020 14:17:33.4491 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: p4P9y1g50YDsueBaTVZizLSpk/l3tTwiRXO8BGixvZTaQWi4b8lGXS3gYoRbE+b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2737 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 14:17:40 -0000 --_000_BN7PR11MB2547B5916BD602946FF64906CFC30BN7PR11MB2547namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QlRXOiBQZXJoYXBzIGp1c3QgdGhlIHByZWZlcnJlZCBsaWZldGltZSBzaG91bGQgYmUgY2FwcGVk Pw0KDQoNCiAgKiAgIEJlcm5pZQ0KDQpGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9y Zz4gT24gQmVoYWxmIE9mIEJlcm5pZSBWb2x6ICh2b2x6KQ0KU2VudDogVHVlc2RheSwgQXByaWwg NywgMjAyMCAxMDoxMiBBTQ0KVG86IExvcmVuem8gQ29saXR0aSA8bG9yZW56bz00MGdvb2dsZS5j b21AZG1hcmMuaWV0Zi5vcmc+OyBPbGUgVHJvYW4gPG90cm9hbkBlbXBsb3llZXMub3JnPg0KQ2M6 IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBXRyBMYXN0IENhbGwgb24gZHJh ZnQtaWV0Zi12Nm9wcy1jcGUtc2xhYWMtcmVudW0NCg0KWXVwLCB0aGF0IGlzIGV4YWN0bHkgd2hh dCBJIHRob3VnaHQgd2FzIGJlaW5nIHN1Z2dlc3RlZCBhbmQgSSB0aGluayBtYWtlcyBnb29kIHNl bnNlLg0KDQoNClRoZSBvbmx5IGhhcm0gdGhhdCB1c2luZyBjYXBwZWQgbGlmZXRpbWVzIChpbnN0 ZWFkIG9mIHRoZSBmdWxsIFBEIGxpZmV0aW1lKSBpcyB0aGF0IGlmIHRoZSBDUEUgZGV2aWNlIGl0 c2VsZiBnb2VzIGRvd24sIHRoZSBHTEFzIG1heSBiZSBsb3N0IHByZW1hdHVyZWx5LiBJZiB0aGUg Q1BFIGlzIG9wZXJhdGluZywgaXQgd2lsbCBjb250aW51ZSB0byBzZW5kIG91dCBSQXMgKHVudGls IHRoZSBsaWZldGltZSBleHBpcmVzKS4NCg0KDQoNCkFuZCB3aXRoIGNhcHMgc3VmZmljaWVudGx5 IGhpZ2gsIFRDUCBjb25uZWN0aW9ucyB3aWxsIGFsbW9zdCBjZXJ0YWlubHkgaGF2ZSB0aW1lZCBv dXQgYnkgdGhlIHRpbWUgdGhlIGNhcHBlZCBsaWZldGltZXMgZXhwaXJlcy4NCg0KDQogICogICBC ZXJuaWUNCg0KRnJvbTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBP ZiBMb3JlbnpvIENvbGl0dGkNClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDcsIDIwMjAgMTA6MDYgQU0N ClRvOiBPbGUgVHJvYW4gPG90cm9hbkBlbXBsb3llZXMub3JnPg0KQ2M6IHY2b3BzQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBXRyBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi12Nm9wcy1j cGUtc2xhYWMtcmVudW0NCg0KT24gVHVlLCBBcHIgNywgMjAyMCBhdCAxMDo1OSBQTSA8b3Ryb2Fu QGVtcGxveWVlcy5vcmc8bWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3JnPj4gd3JvdGU6DQo+IFdo eSBjYW4ndCB3ZSBnbyBldmVuIGZ1cnRoZXIgYW5kIGp1c3Qgc3VnZ2VzdCB0aGF0IHRoZSBtYXhp bXVtIGxpZmV0aW1lcyBiZSBjYXBwZWQgdG8gc29tZSByZWFzb25hYmxlIHZhbHVlLCBzdWNoIGFz IGEgZmV3IGhvdXJzIG9yIGEgZGF5Pw0KPiBJIHRoaW5rIHRoaXMgaXMgd2hhdCBJIHRoaW5rIG1h a2VzIHRoZSBtb3N0IHNlbnNlLiAgRG8gb3BlcmF0b3JzIHRoaW5rIHRoZXJlIGlzIGEgcmVhc29u IHRvIGhhdmUgdGhlIHN1cGVyIGxvbmcgYWRkcmVzc2VzPw0KDQpMaWtlIGNhcCB0aGVtIHRvIDY0 IGJpdCB5b3UgbWVhbj8gOy0pDQoNClVzZXJzIHRoaW5rIHRoZXJlIGFyZSBtYW55IHJlYXNvbnMg dG8gaGF2ZSBsb25nIGxpdmVkIGFkZHJlc3Nlcy4NCkkgdGhpbmsgdGhpcyBpZGVhIG9mIHRyeWlu ZyB0byBtYWtlIGFkZHJlc3MgbGlmZXRpbWVzIGFjdCBhcyBkZWFkIHRpbWVycyBmb3IgcmVhY2hh YmlsaXR5IHNldmVyZWx5IGJyb2tlbi4NCg0KUm91dGluZyAhPSBBZGRyZXNzaW5nLg0KDQpUbyBi ZSBjbGVhcjogSSdtIG5vdCBzdWdnZXN0aW5nIHRoZSBtYXhpbXVtIGxpZmV0aW1lIGJlIGNhcHBl ZCB3aXRoaW4gdGhlIHJvdXRlci4gSSdtIHN1Z2dlc3RpbmcgdGhlIG1heGltdW0gbGlmZXRpbWUg YmUgY2FwcGVkICppbiB0aGUgUkEqLiBJbiBvdGhlciB3b3JkcywgaWYgYW4gSVNQIGFubm91bmNl cyBhIGxpZmV0aW1lIG9mIDEwMCB5ZWFycywgdGhlIFJBIHdvdWxkIHN0aWxsIGNvbnRhaW4gc29t ZXRoaW5nIGxpa2UgOTAwMCBzZWNvbmRzLCA4NjQwMCBzZWNvbmRzLCBvciB3aGF0ZXZlciB2YWx1 ZSB3ZSBwaWNrLiBTbyB5ZXMgLSBpZiB0aGUgcm91dGVyIHdlbnQgYXdheSBmb3IgbW9yZSB0aGFu IDkwMDAvODY0MDAvLi4uIHNlY29uZHMgdGhlIGFkZHJlc3NlcyB3b3VsZCBiZWNvbWUgaW52YWxp ZC4gUmF0aW9uYWxlOiBJIHRoaW5rIGFuIGFkZHJlc3MgaXNuJ3QgdmVyeSB1c2VmdWwgaWYgeW91 IGNhbid0IHVzZSBpdCB0byByZWNlaXZlIHBhY2tldHMuIChJIGtub3cgeW91IGRvbid0IGFncmVl IHdpdGggbWUgb24gdGhpcywgYnV0IG90aGVycyBtaWdodC4pDQo= --_000_BN7PR11MB2547B5916BD602946FF64906CFC30BN7PR11MB2547namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxh aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5Q bGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjE3NjgwMzQ2Mzg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMTgwNjUwMzkyIDgzMDI2MzIyNiA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJ e21zby1saXN0LWlkOjE4MDczMDk3MjQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3MzE4OTcy OTg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoyMTMyNDM1ODI4Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTc0ODQzODYyIDgzMDI2 MzIyNiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1m b250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwy OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CVFc6 IFBlcmhhcHMganVzdCB0aGUgcHJlZmVycmVkIGxpZmV0aW1lIHNob3VsZCBiZSBjYXBwZWQ/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBs Zm80Ij5CZXJuaWU8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiB2Nm9wcyAmbHQ7djZvcHMtYm91bmNlc0Bp ZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkJlcm5pZSBWb2x6ICh2b2x6KTxicj4N CjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCA3LCAyMDIwIDEwOjEyIEFNPGJyPg0KPGI+VG86 PC9iPiBMb3JlbnpvIENvbGl0dGkgJmx0O2xvcmVuem89NDBnb29nbGUuY29tQGRtYXJjLmlldGYu b3JnJmd0OzsgT2xlIFRyb2FuICZsdDtvdHJvYW5AZW1wbG95ZWVzLm9yZyZndDs8YnI+DQo8Yj5D Yzo8L2I+IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIFdH IExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLXY2b3BzLWNwZS1zbGFhYy1yZW51bTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WXVwLCB0aGF0IGlzIGV4YWN0bHkgd2hhdCBJ IHRob3VnaHQgd2FzIGJlaW5nIHN1Z2dlc3RlZCBhbmQgSSB0aGluayBtYWtlcyBnb29kIHNlbnNl LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgb25seSBoYXJtIHRoYXQgdXNpbmcgY2Fw cGVkIGxpZmV0aW1lcyAoaW5zdGVhZCBvZiB0aGUgZnVsbCBQRCBsaWZldGltZSkgaXMgdGhhdCBp ZiB0aGUgQ1BFIGRldmljZSBpdHNlbGYgZ29lcyBkb3duLCB0aGUgR0xBcyBtYXkgYmUgbG9zdCBw cmVtYXR1cmVseS4gSWYgdGhlIENQRSBpcyBvcGVyYXRpbmcsIGl0IHdpbGwgY29udGludWUgdG8g c2VuZCBvdXQgUkFzICh1bnRpbCB0aGUgbGlmZXRpbWUgZXhwaXJlcykuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkFuZCB3aXRoIGNhcHMgc3VmZmljaWVudGx5IGhpZ2gsIFRDUCBjb25u ZWN0aW9ucyB3aWxsIGFsbW9zdCBjZXJ0YWlubHkgaGF2ZSB0aW1lZCBvdXQgYnkgdGhlIHRpbWUg dGhlIGNhcHBlZCBsaWZldGltZXMgZXhwaXJlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPkJlcm5pZTxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gdjZvcHMgJmx0O3Y2b3BzLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpMb3JlbnpvIENvbGl0dGk8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgQXByaWwgNywgMjAyMCAxMDowNiBBTTxicj4NCjxiPlRvOjwvYj4g T2xlIFRyb2FuICZsdDtvdHJvYW5AZW1wbG95ZWVzLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IHY2 b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIFdHIExhc3QgQ2Fs bCBvbiBkcmFmdC1pZXRmLXY2b3BzLWNwZS1zbGFhYy1yZW51bTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXByIDcsIDIwMjAgYXQgMTA6NTkgUE0gJmx0Ozxh IGhyZWY9Im1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm90cm9h bkBlbXBsb3llZXMub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgV2h5IGNhbid0IHdlIGdvIGV2ZW4gZnVydGhlciBhbmQg anVzdCBzdWdnZXN0IHRoYXQgdGhlIG1heGltdW0gbGlmZXRpbWVzIGJlIGNhcHBlZCB0byBzb21l IHJlYXNvbmFibGUgdmFsdWUsIHN1Y2ggYXMgYSBmZXcgaG91cnMgb3IgYSBkYXk/PGJyPg0KJmd0 OyBJIHRoaW5rIHRoaXMgaXMgd2hhdCBJIHRoaW5rIG1ha2VzIHRoZSBtb3N0IHNlbnNlLiZuYnNw OyBEbyBvcGVyYXRvcnMgdGhpbmsgdGhlcmUgaXMgYSByZWFzb24gdG8gaGF2ZSB0aGUgc3VwZXIg bG9uZyBhZGRyZXNzZXM/PGJyPg0KPGJyPg0KTGlrZSBjYXAgdGhlbSB0byA2NCBiaXQgeW91IG1l YW4/IDstKTxicj4NCjxicj4NClVzZXJzIHRoaW5rIHRoZXJlIGFyZSBtYW55IHJlYXNvbnMgdG8g aGF2ZSBsb25nIGxpdmVkIGFkZHJlc3Nlcy48YnI+DQpJIHRoaW5rIHRoaXMgaWRlYSBvZiB0cnlp bmcgdG8gbWFrZSBhZGRyZXNzIGxpZmV0aW1lcyBhY3QgYXMgZGVhZCB0aW1lcnMgZm9yIHJlYWNo YWJpbGl0eSBzZXZlcmVseSBicm9rZW4uPGJyPg0KPGJyPg0KUm91dGluZyAhPSBBZGRyZXNzaW5n LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VG8gYmUgY2xlYXI6IEknbSBub3Qgc3VnZ2VzdGluZyB0aGUgbWF4aW11bSBsaWZldGlt ZSBiZSBjYXBwZWQgd2l0aGluIHRoZSByb3V0ZXIuIEknbSBzdWdnZXN0aW5nIHRoZSBtYXhpbXVt IGxpZmV0aW1lIGJlIGNhcHBlZCAqaW4gdGhlIFJBKi4gSW4gb3RoZXIgd29yZHMsIGlmIGFuIElT UCBhbm5vdW5jZXMgYSBsaWZldGltZSBvZiAxMDAgeWVhcnMsIHRoZSBSQSB3b3VsZCBzdGlsbCBj b250YWluIHNvbWV0aGluZw0KIGxpa2UgOTAwMCBzZWNvbmRzLCA4NjQwMCBzZWNvbmRzLCBvciB3 aGF0ZXZlciB2YWx1ZSB3ZSBwaWNrLiBTbyB5ZXMgLSBpZiB0aGUgcm91dGVyIHdlbnQgYXdheSBm b3IgbW9yZSB0aGFuIDkwMDAvODY0MDAvLi4uIHNlY29uZHMgdGhlIGFkZHJlc3NlcyB3b3VsZCBi ZWNvbWUgaW52YWxpZC4gUmF0aW9uYWxlOiBJIHRoaW5rIGFuIGFkZHJlc3MgaXNuJ3QgdmVyeSB1 c2VmdWwgaWYgeW91IGNhbid0IHVzZSBpdCB0byByZWNlaXZlIHBhY2tldHMuIChJDQoga25vdyB5 b3UgZG9uJ3QgYWdyZWUgd2l0aCBtZSBvbiB0aGlzLCBidXQgb3RoZXJzIG1pZ2h0Lik8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_BN7PR11MB2547B5916BD602946FF64906CFC30BN7PR11MB2547namp_-- From nobody Tue Apr 7 07:36:35 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CD93A0B11 for ; Tue, 7 Apr 2020 07:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgGjiginwi1m for ; Tue, 7 Apr 2020 07:36:32 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE26D3A0B0B for ; Tue, 7 Apr 2020 07:36:32 -0700 (PDT) Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id F19C34E11AED; Tue, 7 Apr 2020 14:36:31 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 4652F316A801; Tue, 7 Apr 2020 16:36:25 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: <14E3E429-B9C4-45F0-AA06-450580843EB2@fugue.com> Date: Tue, 7 Apr 2020 16:36:25 +0200 Cc: Timothy Winters , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters Content-Transfer-Encoding: quoted-printable Message-Id: References: <14E3E429-B9C4-45F0-AA06-450580843EB2@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 14:36:34 -0000 Ted, >> I think this idea of trying to make address lifetimes act as dead = timers for reachability severely broken. >=20 > I think that in principle this is true, but I=E2=80=99m not sure that = it follows in practice. What should we be doing instead? Or was this = just a miscommunication, per Lorenzo=E2=80=99s clarifying message? >=20 > My experience with this tends to make me want to agree with Lorenzo. = The longer a PIO prefix lifetime is, the longer things are broken when = the router stops advertising the prefix without deprecating it. OTOH, = it=E2=80=99s _always_ going to be too long, so as you say, we really = want a better way to detect that we have a problem. Right now if one = device remembers a stale on-link prefix that another device has not = seen, the first device may choose that stale prefix during source = address selection, and of course since the second device doesn=E2=80=99t = see it as on-link, this will fail. >=20 > How do we quickly detect this failure? Exactly. It doesn't much matter if the prefix lifetime is 100 years or = two hours. The user isn't going to sit around for that time anyway. slaac-renum solves a small corner case of this problem space. I suggest the rest of that discussion happens in 6man. Best regards, Ole From nobody Tue Apr 7 07:37:17 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F233A0A4F for ; Tue, 7 Apr 2020 07:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8CLNztXmu0P for ; Tue, 7 Apr 2020 07:37:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505F23A0C98 for ; Tue, 7 Apr 2020 07:36:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jLpLN-0000IsC; Tue, 7 Apr 2020 16:36:49 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <61AA2CA9-FE8A-4ACF-8D77-CABC46C56831@employees.org> In-reply-to: Your message of "Tue, 7 Apr 2020 18:26:59 +1000 ." Date: Tue, 07 Apr 2020 16:36:49 +0200 Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 14:37:16 -0000 >Imagine a home user continuing to try to illegitimately use as a source >address what is now somebody else's PD prefix because they overrode the >ISP's lifetimes. Any sensible ISP does ingress filtering. Today people can already configure addresses statically. Worse, people have been abusing other people's IPv4 addresses in various ways. From nobody Tue Apr 7 09:28:03 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6433A0D03 for ; Tue, 7 Apr 2020 09:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 6GvZg7V5qxOo for ; Tue, 7 Apr 2020 09:27:59 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61FF33A0D02 for ; Tue, 7 Apr 2020 09:27:59 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 8415B893D4; Tue, 7 Apr 2020 18:27:56 +0200 (CEST) To: Lorenzo Colitti , Ole Troan Cc: "v6ops@ietf.org" References: From: Fernando Gont Message-ID: Date: Tue, 7 Apr 2020 13:26:56 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 16:28:01 -0000 On 7/4/20 11:05, Lorenzo Colitti wrote: > On Tue, Apr 7, 2020 at 10:59 PM > wrote: > > > Why can't we go even further and just suggest that the maximum > lifetimes be capped to some reasonable value, such as a few hours or > a day? > > I think this is what I think makes the most sense.  Do operators > think there is a reason to have the super long addresses? > > Like cap them to 64 bit you mean? ;-) > > Users think there are many reasons to have long lived addresses. > I think this idea of trying to make address lifetimes act as dead > timers for reachability severely broken. > > Routing != Addressing. > > > To be clear: I'm not suggesting the maximum lifetime be capped within > the router. I'm suggesting the maximum lifetime be capped *in the RA*. > In other words, if an ISP announces a lifetime of 100 years, the RA > would still contain something like 9000 seconds, 86400 seconds, or > whatever value we pick. So yes - if the router went away for more than > 9000/86400/... seconds the addresses would become invalid. Rationale: I > think an address isn't very useful if you can't use it to receive > packets. (I know you don't agree with me on this, but others might.) FWIW, I agree with that idea. And that's the rationale for my suggestion in the other email. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 7 09:33:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F51D3A0F8C for ; Tue, 7 Apr 2020 09:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 gJtlFCa375lM for ; Tue, 7 Apr 2020 09:33:38 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F4C3A0F22 for ; Tue, 7 Apr 2020 09:33:32 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 7890280F74; Tue, 7 Apr 2020 18:23:47 +0200 (CEST) To: Lorenzo Colitti , Owen DeLong Cc: "v6ops@ietf.org" , Timothy Winters References: From: Fernando Gont Message-ID: Date: Tue, 7 Apr 2020 13:23:22 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 16:33:48 -0000 On 7/4/20 10:48, Lorenzo Colitti wrote: > On Tue, Apr 7, 2020 at 6:47 AM Owen DeLong > wrote: > >> By recommending that lifetimes should be dynamically updated, this >> draft will defeat devices that do #2. Based on past experience, a >> likely outcome is that manufacturers will react by switching to #1 >> and dropping all RAs. We should try to avoid making this problem >> worse with this draft. > But if you don’t update the lifetimes, then you’re handing out PIOs > that contain a lifetime beyond the end of the IA_PD lease. > > Could we perhaps recommend sending out PIOs that are 1/4 or 1/3 of > the original IA_PD lease so long as the lease is renewed and then > dynamically counting down to 0 such that the PIO never contains a > lifetime longer than the IA_PD validity? > > This should provide a best of both worlds… Until the IA_PD expires > without renewal, the PIO should contain a fixed lifetime, but in the > (rare) case where a prefix is expiring, we sacrifice some battery > life to avoid a loss of connectivity. > > > Why can't we go even further and just suggest that the maximum lifetimes > be capped to some reasonable value, such as a few hours or a day? Yes, that's indeed the outcome of this discussion. I will repost the corresponding proposed text in a separate thread, since it might have got lost in the recent flood of emails. But, essentially, the idea was to set the Preferred Lifetime and Valid Lifetime of PIOs to the Router Lifetime and X * Router Lifetime, respectively, and also hinting RFC7772. (If the lifetimes are kept short enough (as indicated), and the prefix is renewed before any of those lifetimes expire, you wouldn't even need to change the PIO lifetimes you advertise on the LAN side) Would that work for you? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 7 10:28:09 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033AF3A0A83 for ; Tue, 7 Apr 2020 10:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBXNAuMKa18M for ; Tue, 7 Apr 2020 10:28:05 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68EB3A0A81 for ; Tue, 7 Apr 2020 10:28:05 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79d:53aa:d30:5993:9b47:c769:f1e9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id D69C24E11AED; Tue, 7 Apr 2020 17:28:04 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id A43553170FE1; Tue, 7 Apr 2020 19:27:58 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Tue, 7 Apr 2020 19:27:58 +0200 Cc: Timothy Winters , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 17:28:07 -0000 Lorenzo, > Like cap them to 64 bit you mean? ;-) >=20 > Users think there are many reasons to have long lived addresses. > I think this idea of trying to make address lifetimes act as dead = timers for reachability severely broken. >=20 > Routing !=3D Addressing. >=20 > To be clear: I'm not suggesting the maximum lifetime be capped within = the router. I'm suggesting the maximum lifetime be capped *in the RA*. = In other words, if an ISP announces a lifetime of 100 years, the RA = would still contain something like 9000 seconds, 86400 seconds, or = whatever value we pick. So yes - if the router went away for more than = 9000/86400/... seconds the addresses would become invalid. Rationale: I = think an address isn't very useful if you can't use it to receive = packets. (I know you don't agree with me on this, but others might.) What problem does this solve? (and I doubt v6ops is the place to for this.) Cheers, Ole= From nobody Tue Apr 7 14:26:41 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A7C3A149E for ; Tue, 7 Apr 2020 14:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 w5Mgc-8j0lar for ; Tue, 7 Apr 2020 14:26:38 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC163A1509 for ; Tue, 7 Apr 2020 14:25:55 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 037LPrMn1471329 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Apr 2020 14:25:55 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 037LPrMn1471329 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586294755; bh=htg91g5GNIpiGBvjyBH49ZMMGnnBGMAhhCFD3PDdpkk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Hj1K2M3JZz2e7Vu/BxnxFn1MlSu+lJFojn8vSQc2fnTizsqvRY8lK1SjEXTGTxEXX FGMU1wYE/qcqDNuWdnpb+4PxvQO3BbK/CeFiAwDzAvX8Nshr/P9HAn9K18R4B81dOx FsCtgNn3ZBlng/hxhOAPmsBEjKv9MhOhQqb1S7bQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: Date: Tue, 7 Apr 2020 14:25:53 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> To: Philip Homburg X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Tue, 07 Apr 2020 14:25:55 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 21:26:40 -0000 > On Apr 6, 2020, at 14:17 , Philip Homburg = wrote: >=20 >>> That said, setting, the PIO lifetimes in a way that would span past=20= >> the DHCPV6-PD would be incorrect. >>=20 >> Yes, that would violate a fundamental premise of prefix delegation. >=20 > I disagree. In case of a static prefix it should be possible for the > user of the router to set long lifetimes. By definition if it is spanning a DHCPv6-PD issued lifetime, it is NOT a = static prefix. What am I missing? Owen From nobody Tue Apr 7 14:30:03 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025033A153D for ; Tue, 7 Apr 2020 14:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Qmmhy35uuDGt for ; Tue, 7 Apr 2020 14:29:59 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 86A7F3A1539 for ; Tue, 7 Apr 2020 14:29:59 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 037LTrMa1472742 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Apr 2020 14:29:54 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 037LTrMa1472742 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586294995; bh=MWH5IWmkz2/YR6W/qd59ii85HuJUHs8GNnKTEz9PqtA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=pqBePzEZyyGR5lidnQIvurnZB3tzx7PgX3oGrewE/lsRhiFo0pgpQt39/+dHeG1fH oFJ/DIOV2qMjpCo6WbYfXCcpBrg1RXDeCBkMtLnmfXjxApmrLOgqNPcSp7MEunJnlY QMgAjRYYM89Xcums5ZGgKpsssxWig+DHCDNSm/bQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: Date: Tue, 7 Apr 2020 14:29:53 -0700 Cc: Fernando Gont , "otroan@employees.org" , Ron Bonica , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5C80CE87-46E6-4F5C-B1C1-BB19878075EA@delong.com> References: <52688D39-5537-44BA-B1C8-4341C21D1B02@employees.org> <6186B94B-2504-48C7-8A20-AEB5896D1BB1@employees.org> <56667bf5-97ac-5427-6d75-7ff4f32bf946@si6networks.com> <831536da-bab1-9370-b4db-dd643fa2f022@si6networks.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Tue, 07 Apr 2020 14:29:55 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 21:30:01 -0000 > On Apr 6, 2020, at 15:04 , Bernie Volz (volz) = wrote: >=20 > BTW: And problem to ponder ... >=20 > CPE has no storage. Uh, then where do they keep their updatable firmware, exactly? > DHCPv6 sends PDs, one (or some) with 0 lifetimes. Other(s) with = non-zero lifetimes. >=20 > So, what should a CPE do? How long should it continue to send out the = RAs with PIOs regarding the prefixes with 0 lifetimes? For a PD with 0 lifetime, it should apply the prefix to its interfaces = and route packets to/from that prefix. It should not put them in PIOs. This way, clients that have lifetime left from previous PIOs are not = disabled, but new clients are given the most current information. > It would have to do this until it stopped receiving the PDs with 0 = lifetimes in a Reply to a Request, Renew, or Rebind. This is because the = CPE would have no knowledge of the original lifetime and when that PD = could safely stop being advertised. And, the DHCPv6 messaging has no way = to communicate what the original (remaining) lifetime may have been. Yes. Hence the preference that the device record the information = locally. > So, wouldn't this need to be documented somewhere? Or is this = something we think everyone implementing a CPE would understand it needs = to do? It would be good to add this to the document, IMHO. Fernando? Owen >=20 > - Bernie >=20 > -----Original Message----- > From: Fernando Gont =20 > Sent: Monday, April 6, 2020 5:23 PM > To: Bernie Volz (volz) ; otroan@employees.org > Cc: Ron Bonica ; = v6ops@ietf.org; Timothy Winters > Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum >=20 > On 6/4/20 18:15, Bernie Volz (volz) wrote: > [....] >> Since the DHCPv6-PD client could come back anytime withing the = DHCPv6-PD >> lease time of the stale prefix, the DHCPv6 server would need to = remember >> this for such period of time. I assume that's what Bernie meant. >>=20 >> BV> Correct. The server would be obligated to retain it until the = (longest) valid lifetime it had sent the client expired. The question is = how the server knows when a DHCP exchange is complete (just because it = sent a Reply is not a guarantee the client received it). And, if it does = use that then the issue is that this doesn't help the CPE if it rebooted = after this (or even) several exchanges as there could still be clients = behind the CPE that have not received an updated RA with the deprecated = prefix. >=20 > Completely agree. If anything, this would relieve the CPE from having = to store the leased prefix themselves, but: >=20 > 1) Since the CPE can't know a priori if the DHCPv6 server will, it = should record the prefix in order to fail on the safe side. >=20 > 2) I'm curious what typical CPEs do upon receipt of multiple prefixes = via DHCPv6-PD, and also what they do if they receive them, but some have = zero lifetimes. (I wouldn't surprise if they only use one, and even less = surprised if PIOs with zero lifetimes are simply dropped). Tim? >=20 > Thanks! >=20 > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Apr 7 14:32:52 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8244C3A03FE for ; Tue, 7 Apr 2020 14:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbMw1sA4hxOV for ; Tue, 7 Apr 2020 14:32:48 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE9D3A040C for ; Tue, 7 Apr 2020 14:32:48 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 037LWkQr1473661 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Apr 2020 14:32:46 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 037LWkQr1473661 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586295167; bh=Fi7VKa/eShzMqhp6wPVjp86AOaepg7fra6ciGPzwYGs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=QgW8llnSvdHIMom4Dn4yBAZrcKNh1D0RJ5x9DxRL6moKJQO4CrOFpgLQ8MnL0N75F yHcYDt5CPDNTReCTQvOk2gRSI34xDEQrJmhOXA1pv/zIAkwmFHZ9yHOje+LKpbMhNB udh1uX8zf9E85+EO74oBduL0V3lJtyi8EdqErBck= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <42c901f8-7a67-1999-1210-272656ef6c9f@si6networks.com> Date: Tue, 7 Apr 2020 14:32:46 -0700 Cc: Timothy Winters , Ron Bonica , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <30F11A59-1DB2-4D2F-8E2B-B39394FF5DF6@delong.com> References: <52688D39-5537-44BA-B1C8-4341C21D1B02@employees.org> <6186B94B-2504-48C7-8A20-AEB5896D1BB1@employees.org> <56667bf5-97ac-5427-6d75-7ff4f32bf946@si6networks.com> <831536da-bab1-9370-b4db-dd643fa2f022@si6networks.com> <42c901f8-7a67-1999-1210-272656ef6c9f@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Tue, 07 Apr 2020 14:32:47 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 21:32:51 -0000 > On Apr 6, 2020, at 16:46 , Fernando Gont = wrote: >=20 > On 6/4/20 20:37, Timothy Winters wrote: > [...] >> 2) I'm curious what typical CPEs do upon receipt of multiple = prefixes >> via DHCPv6-PD, and also what they do if they receive them, but = some >> have >> zero lifetimes. (I wouldn't surprise if they only use one, and = even >> less >> surprised if PIOs with zero lifetimes are simply dropped). Tim? >> IPv6 Ready has a test for Prefix Change that sends IA_PDs with one = valid and one with zero. So we test and IPv6 Ready Logo CE Routers do = this perfectly. When I was at the lab this was the most failed test = case, in all the ways you can imagine. I came to really hate this test = case over the last 4 four years. >=20 > Failed on the CPE side, router side, or both? And... any idea if this = ever improved significantly? Or show we still assume CPEs to be buggy in = this respect? In general, it is relatively safe to assume that CPEs will be buggy in = pretty much every respect. New CPEs frequently recycle long dead bugs in my experience. Owen From nobody Tue Apr 7 14:34:33 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09213A0522 for ; Tue, 7 Apr 2020 14:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ouC-Rj2sZmmR for ; Tue, 7 Apr 2020 14:34:31 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE343A0484 for ; Tue, 7 Apr 2020 14:34:31 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 037LYPuW1474349 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Apr 2020 14:34:26 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 037LYPuW1474349 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586295266; bh=ioTobBtM4oaNAHnC8Kvq5WNP3CL2DbIQFJqg6tMyIVU=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=1Pagljkm3vUhnvSakwZLkgYEimdMYYzBIX9uRcVfsiS2ih7S/sAofYIBgykRfMxrL GSFE/mOOc0dx/Ubl/XPN4FI6+d4Ia022qAB5Itaj4CFKBYrhWINlVkDyuA/mRPGRcG HaOhGiTDG5f7kudqsdocX3vV2duWxT7BQ98Z69bs= From: Owen DeLong Message-Id: <9243ADE6-E219-49CE-82E2-757106534FEC@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0D357105-1464-4873-9C47-6482C2DF701E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 7 Apr 2020 14:34:25 -0700 In-Reply-To: Cc: Ron Bonica , Timothy Winters , "v6ops@ietf.org" To: Lorenzo Colitti References: X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Tue, 07 Apr 2020 14:34:26 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 21:34:33 -0000 --Apple-Mail=_0D357105-1464-4873-9C47-6482C2DF701E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 7, 2020, at 06:48 , Lorenzo Colitti wrote: >=20 > On Tue, Apr 7, 2020 at 6:47 AM Owen DeLong > wrote: >> By recommending that lifetimes should be dynamically updated, this = draft will defeat devices that do #2. Based on past experience, a likely = outcome is that manufacturers will react by switching to #1 and dropping = all RAs. We should try to avoid making this problem worse with this = draft. > But if you don=E2=80=99t update the lifetimes, then you=E2=80=99re = handing out PIOs that contain a lifetime beyond the end of the IA_PD = lease. >=20 > Could we perhaps recommend sending out PIOs that are 1/4 or 1/3 of the = original IA_PD lease so long as the lease is renewed and then = dynamically counting down to 0 such that the PIO never contains a = lifetime longer than the IA_PD validity? >=20 > This should provide a best of both worlds=E2=80=A6 Until the IA_PD = expires without renewal, the PIO should contain a fixed lifetime, but in = the (rare) case where a prefix is expiring, we sacrifice some battery = life to avoid a loss of connectivity. >=20 > Why can't we go even further and just suggest that the maximum = lifetimes be capped to some reasonable value, such as a few hours or a = day? I have no objection to that=E2=80=A6 However, once the PD lifetime drops = below this value, whatever it is, RAs shouldn=E2=80=99t be advertising a = larger number and therefore have to dynamically adjust as it counts = down. Owen --Apple-Mail=_0D357105-1464-4873-9C47-6482C2DF701E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 7, 2020, at 06:48 , Lorenzo Colitti <lorenzo@google.com> = wrote:

On Tue, Apr 7, 2020 = at 6:47 AM Owen DeLong <owen@delong.com> wrote:
By = recommending that lifetimes should be dynamically updated, this draft = will defeat devices that do #2. Based on past experience, a likely = outcome is that manufacturers will react by switching to #1 and dropping = all RAs. We should try to avoid making this problem worse with this = draft.
But if you don=E2=80=99t update the = lifetimes, then you=E2=80=99re handing out PIOs that contain a lifetime = beyond the end of the IA_PD lease.

Could we perhaps recommend sending out = PIOs that are 1/4 or 1/3 of the original IA_PD lease so long as the = lease is renewed and then dynamically counting down to 0 such that the = PIO never contains a lifetime longer than the IA_PD validity?

This should provide a = best of both worlds=E2=80=A6 Until the IA_PD expires without renewal, = the PIO should contain a fixed lifetime, but in the (rare) case where a = prefix is expiring, we sacrifice some battery life to avoid a loss of = connectivity.

Why can't we go even further and just = suggest that the maximum lifetimes be capped to some reasonable value, = such as a few hours or a day?

I have no objection to = that=E2=80=A6 However, once the PD lifetime drops below this value, = whatever it is, RAs shouldn=E2=80=99t be advertising a larger number and = therefore have to dynamically adjust as it counts down.

Owen


= --Apple-Mail=_0D357105-1464-4873-9C47-6482C2DF701E-- From nobody Tue Apr 7 16:29:08 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F9C3A0862 for ; Tue, 7 Apr 2020 16:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 C2Rq6WigPT3M for ; Tue, 7 Apr 2020 16:29:02 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 802933A0863 for ; Tue, 7 Apr 2020 16:29:01 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 07D10893D3; Wed, 8 Apr 2020 01:28:54 +0200 (CEST) To: otroan@employees.org, Ted Lemon Cc: "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters References: <14E3E429-B9C4-45F0-AA06-450580843EB2@fugue.com> From: Fernando Gont Message-ID: <1d115fc4-8a87-9c52-605d-fd0069b4eff3@si6networks.com> Date: Tue, 7 Apr 2020 20:26:15 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 23:29:07 -0000 On 7/4/20 11:36, otroan@employees.org wrote: > Ted, > >>> I think this idea of trying to make address lifetimes act as dead timers for reachability severely broken. >> >> I think that in principle this is true, but I’m not sure that it follows in practice. What should we be doing instead? Or was this just a miscommunication, per Lorenzo’s clarifying message? >> >> My experience with this tends to make me want to agree with Lorenzo. The longer a PIO prefix lifetime is, the longer things are broken when the router stops advertising the prefix without deprecating it. OTOH, it’s _always_ going to be too long, so as you say, we really want a better way to detect that we have a problem. Right now if one device remembers a stale on-link prefix that another device has not seen, the first device may choose that stale prefix during source address selection, and of course since the second device doesn’t see it as on-link, this will fail. >> >> How do we quickly detect this failure? > > Exactly. It doesn't much matter if the prefix lifetime is 100 years or two hours. The user isn't going to sit around for that time anyway. Reducing the preferred lifetime essentially improves the time it takes to deprecate and subsequently eliminate addresses corresponding to a router that simply disappears. It's not perfect, but it way better than what we currently have. (but see below). > slaac-renum solves a small corner case of this problem space. slaac-renum mitigates the case described above, *and* also solves in a very efficient and timely manner handle the case where e.g. a CE Router crashes and reboots. I'm not sure what's your definition of corner-case -- but this is a very common scenario. And, as it should be clear from this discussion, there are multiple reasons for which such scenarios could take place (CPE crashes and reboots, CPE announces PIOs with a lifetime that spans past the DHCPv6-PD lease, etc.) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 7 16:47:12 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4329C3A0366 for ; Tue, 7 Apr 2020 16:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 UfZSREGhQhKO for ; Tue, 7 Apr 2020 16:47:08 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DF83A0365 for ; Tue, 7 Apr 2020 16:47:08 -0700 (PDT) Received: from [IPv6:2a02:2121:301:9de0:8982:e75f:b53e:dad2] (unknown [IPv6:2a02:2121:301:9de0:8982:e75f:b53e:dad2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 91B5D4E11AED; Tue, 7 Apr 2020 23:47:07 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Wed, 8 Apr 2020 01:47:05 +0200 Message-Id: <522CDB81-37AE-4D27-B6F3-B3A49B53054D@employees.org> References: <1d115fc4-8a87-9c52-605d-fd0069b4eff3@si6networks.com> Cc: Ted Lemon , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters In-Reply-To: <1d115fc4-8a87-9c52-605d-fd0069b4eff3@si6networks.com> To: Fernando Gont X-Mailer: iPhone Mail (17E255) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2020 23:47:11 -0000 Fernando, > On 8 Apr 2020, at 01:29, Fernando Gont wrote: >=20 > =EF=BB=BFOn 7/4/20 11:36, otroan@employees.org wrote: >> Ted, >>>> I think this idea of trying to make address lifetimes act as dead timer= s for reachability severely broken. >>>=20 >>> I think that in principle this is true, but I=E2=80=99m not sure that it= follows in practice. What should we be doing instead? Or was this just a m= iscommunication, per Lorenzo=E2=80=99s clarifying message? >>>=20 >>> My experience with this tends to make me want to agree with Lorenzo. Th= e longer a PIO prefix lifetime is, the longer things are broken when the rou= ter stops advertising the prefix without deprecating it. OTOH, it=E2=80=99s= _always_ going to be too long, so as you say, we really want a better way t= o detect that we have a problem. Right now if one device remembers a stale o= n-link prefix that another device has not seen, the first device may choose t= hat stale prefix during source address selection, and of course since the se= cond device doesn=E2=80=99t see it as on-link, this will fail. >>>=20 >>> How do we quickly detect this failure? >> Exactly. It doesn't much matter if the prefix lifetime is 100 years or tw= o hours. The user isn't going to sit around for that time anyway. >=20 > Reducing the preferred lifetime essentially improves the time it takes to d= eprecate and subsequently eliminate addresses corresponding to a router that= simply disappears. >=20 > It's not perfect, but it way better than what we currently have. (but see b= elow). It=E2=80=99s a fool=E2=80=99s errand to think you will fix this with short l= ifetimes. Either they are so short that they expire during a link flap or they will re= gardless be so long that it=E2=80=99s beyond an acceptable wait time for a u= ser.=20 >> slaac-renum solves a small corner case of this problem space. >=20 > slaac-renum mitigates the case described above, *and* also solves in a ver= y efficient and timely manner handle the case where e.g. a CE Router crashes= and reboots. I'm not sure what's your definition of corner-case -- but this= is a very common scenario. And, as it should be clear from this discussion,= there are multiple reasons for which such scenarios could take place (CPE c= rashes and reboots, CPE announces PIOs with a lifetime that spans past the D= HCPv6-PD lease, etc.) Not sure what you mean by the case of a cpe crashing and rebooting and why t= hat should matter.=20 And may I remind you that ipv6 hosts are used in a diverse set of networks. Cheers=20 Ole >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From nobody Tue Apr 7 17:02:58 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F403A08B3 for ; Tue, 7 Apr 2020 17:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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 qpcZpbHAQtGk for ; Tue, 7 Apr 2020 17:02:53 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7103A08A7 for ; Tue, 7 Apr 2020 17:02:52 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id y25so4263004qtv.7 for ; Tue, 07 Apr 2020 17:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=CBBJoi0zrDkOuFt7j9x8PPwA66wuVUabFH1O90SJ8FI=; b=f/pqD6aHrS7WZfZXnve67OyIYXDpbil6QO+9U0Zo/S/HtiwfPNLYkrFG+6+ivi8V17 1WY6WiGt+lZ6kqXjrlVoE/xg4IaU5UbdiDQgrbPoxIRr+PwggeHLtqlRKdY2/oJwWLjy W+yY+Kb80CSfVE3D8SSVrWc5ymwL0rkxfNzIanoLIAfje4W0BT92bsEreOiq2IjYNRIp SXXAazwe65ean0VrklW2xuTIrt/K9ZUin4skv9ASBPmok4yixs4/nbashklg7JlLWVO7 kc2jpYvcSY1xx1aM53iFnKI1mGgs5Hqoy4IQGrwsh81Z6QMOO+yj0Xp5p8ZNZRZV1rYI CF5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=CBBJoi0zrDkOuFt7j9x8PPwA66wuVUabFH1O90SJ8FI=; b=c2ONNWZyozGW89+hKHzhVnsfJqeYNwqFeDuztsISTVzqSoAnr0I40ViM9xose1oft3 YZEYk7BG/phn3mOWlqfliF8JW4k4DjukCWb4lDZUY5zuYbjr6cQq4sXCgc3Gr6jRyOKs a+T4m2Xlb6+vZ+fZ3UXmUdifvA+5MjBVxh+JcKjrzrywPZnyNPON33p4mw3TZRu5U5Id tzn2pWP8Cb9T6GqcQJWg4li40Pj3wTJYGb6/1wcwgY+njOj3+JjneBe6JahkIgkqJFrL 3qGbmripCXjj77hi/jLCDgUaDG5DefaHmS8Kfrc62XBFXNltFF4ljyEdCKHRtNP5Hp+G bWzA== X-Gm-Message-State: AGi0PubgglpgpsXyZHSrmI4DUgsseDX+xq1iAeV8XcxIhPY/tdRzLvQA lGtYRFa5728pOZ/Zbd9413bQ/w== X-Google-Smtp-Source: APiQypL8ockEKY93EatptoY5MgfN3Yk4LFklodD5XY1VoasYLBWbh0/Cat7c+aqMjnTcwZJuEh8z0A== X-Received: by 2002:ac8:6f14:: with SMTP id g20mr5061197qtv.53.1586304171766; Tue, 07 Apr 2020 17:02:51 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:cd27:8edc:808b:771e? ([2601:18b:300:36ee:cd27:8edc:808b:771e]) by smtp.gmail.com with ESMTPSA id l9sm488133qth.60.2020.04.07.17.02.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Apr 2020 17:02:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Tue, 7 Apr 2020 20:02:50 -0400 Message-Id: <451C08C9-376F-4275-B8CF-2FD9C194A606@fugue.com> References: <522CDB81-37AE-4D27-B6F3-B3A49B53054D@employees.org> Cc: Fernando Gont , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters In-Reply-To: <522CDB81-37AE-4D27-B6F3-B3A49B53054D@employees.org> To: Ole Troan X-Mailer: iPhone Mail (17F39) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 00:02:57 -0000 It would probably work better to factor preferred lifetimes into source addr= ess selection. iOS, if two source addresses are otherwise equivalent, pick t= he one that=E2=80=99s valid longer.=20 This does argue for capping valid lifetimes in RAs.=20 We could also sort by time of most recent RA.=20 > On Apr 7, 2020, at 19:47, Ole Troan wrote: >=20 > =EF=BB=BFFernando, >=20 >>> On 8 Apr 2020, at 01:29, Fernando Gont wrote: >>>=20 >>> =EF=BB=BFOn 7/4/20 11:36, otroan@employees.org wrote: >>> Ted, >>>>> I think this idea of trying to make address lifetimes act as dead time= rs for reachability severely broken. >>>>=20 >>>> I think that in principle this is true, but I=E2=80=99m not sure that i= t follows in practice. What should we be doing instead? Or was this just a= miscommunication, per Lorenzo=E2=80=99s clarifying message? >>>>=20 >>>> My experience with this tends to make me want to agree with Lorenzo. T= he longer a PIO prefix lifetime is, the longer things are broken when the ro= uter stops advertising the prefix without deprecating it. OTOH, it=E2=80=99= s _always_ going to be too long, so as you say, we really want a better way t= o detect that we have a problem. Right now if one device remembers a stale o= n-link prefix that another device has not seen, the first device may choose t= hat stale prefix during source address selection, and of course since the se= cond device doesn=E2=80=99t see it as on-link, this will fail. >>>>=20 >>>> How do we quickly detect this failure? >>> Exactly. It doesn't much matter if the prefix lifetime is 100 years or t= wo hours. The user isn't going to sit around for that time anyway. >>=20 >> Reducing the preferred lifetime essentially improves the time it takes to= deprecate and subsequently eliminate addresses corresponding to a router th= at simply disappears. >>=20 >> It's not perfect, but it way better than what we currently have. (but see= below). >=20 > It=E2=80=99s a fool=E2=80=99s errand to think you will fix this with short= lifetimes. > Either they are so short that they expire during a link flap or they will r= egardless be so long that it=E2=80=99s beyond an acceptable wait time for a u= ser.=20 >=20 >=20 >>> slaac-renum solves a small corner case of this problem space. >>=20 >> slaac-renum mitigates the case described above, *and* also solves in a ve= ry efficient and timely manner handle the case where e.g. a CE Router crashe= s and reboots. I'm not sure what's your definition of corner-case -- but thi= s is a very common scenario. And, as it should be clear from this discussion= , there are multiple reasons for which such scenarios could take place (CPE c= rashes and reboots, CPE announces PIOs with a lifetime that spans past the D= HCPv6-PD lease, etc.) >=20 > Not sure what you mean by the case of a cpe crashing and rebooting and why= that should matter. >=20 > And may I remind you that ipv6 hosts are used in a diverse set of networks= . >=20 > Cheers=20 > Ole >=20 >>=20 >> Thanks, >> --=20 >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >>=20 >>=20 >>=20 >>=20 From nobody Tue Apr 7 17:56:47 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E653A102A for ; Tue, 7 Apr 2020 17:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 x2zi42-wMWSN for ; Tue, 7 Apr 2020 17:56:38 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54193A102B for ; Tue, 7 Apr 2020 17:56:36 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 F385C893D5; Wed, 8 Apr 2020 02:56:30 +0200 (CEST) To: Ole Troan Cc: Ted Lemon , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters References: <1d115fc4-8a87-9c52-605d-fd0069b4eff3@si6networks.com> <522CDB81-37AE-4D27-B6F3-B3A49B53054D@employees.org> From: Fernando Gont Message-ID: Date: Tue, 7 Apr 2020 21:30:48 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <522CDB81-37AE-4D27-B6F3-B3A49B53054D@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 00:56:46 -0000 On 7/4/20 20:47, Ole Troan wrote: [....] >> >> It's not perfect, but it way better than what we currently have. (but see below). > > It’s a fool’s errand to think you will fix this with short lifetimes. It mitigates the problem -- it doesn't eliminate it. We have timers. We are just not using them appropriately. What's the point of having PL and VL lifetimes in a way that they will never go off in any meaningful timeframe? The PL lifetime could even be reduce to less than the Router Lifetime. At the end of the day, that only changes which addresses you'd use for new connections. If you have another fresher address, that'd me you'd use that address. And if you don't have any other addresses, you'd use the deprectated ones: they are still valid, and you have no better alternatives. > Either they are so short that they expire during a link flap or they will regardless be so long that it’s beyond an acceptable wait time for a user. Please see below. >>> slaac-renum solves a small corner case of this problem space. >> >> slaac-renum mitigates the case described above, *and* also solves in a very efficient and timely manner handle the case where e.g. a CE Router crashes and reboots. I'm not sure what's your definition of corner-case -- but this is a very common scenario. And, as it should be clear from this discussion, there are multiple reasons for which such scenarios could take place (CPE crashes and reboots, CPE announces PIOs with a lifetime that spans past the DHCPv6-PD lease, etc.) > > Not sure what you mean by the case of a cpe crashing and rebooting and why that should matter. Because you receive RAs from the same router that had sent the now stale network configuration information. Hence, the algorithms from Section 4.5 of draft-gont-6man-slaac-renum will deprecate the information in a timely manner. And that's one of the most common scenarios for the problem discussed in draft-ietf-v6ops-slaac-renum. > And may I remind you that ipv6 hosts are used in a diverse set of networks. No need to remind me of that. That has been well considered. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 7 18:00:22 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965E33A1041 for ; Tue, 7 Apr 2020 18:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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 Ku2UGQd7PRdW for ; Tue, 7 Apr 2020 18:00:15 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE7E3A103F for ; Tue, 7 Apr 2020 18:00:15 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id g7so4307520qtj.13 for ; Tue, 07 Apr 2020 18:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=a/XKciMVR3cPxm1DQdDiVQ71xGlduafV2rXu/wJ5ozs=; b=CtrZbmtOUwvPH8OWu0d4bsmIGGaIB8aLdsSjzcXroqRdK4TqGTPsh7jITI3gsYQ8t0 d6T2NU7pzFKf5HyVWnGVmh4L3VKg2LOxXssr6ZIapWFfbxJ6L5VgZ6CtheLtVstyi8/N L3Gu7npFB+v3JerNUZ8k2BEkPdYUxs1kB5RuuDUEyYU3kN7TpGKzVc8vChL+dl3tNNaV 8fhsKFgwJe/pdH01nITjpO25GSMR1XjjRqk3cwFnkZDoPaKQ1+8U/ERXjVVqAhjVv7pi zSaxJl0jrVklxrzVOww03MlZvLRALyKDz8fIjUhoxqccOkCTw6EpjtuTTwFVvFUMyI7e Kp6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=a/XKciMVR3cPxm1DQdDiVQ71xGlduafV2rXu/wJ5ozs=; b=EnraoBIyOTN+LcelNWIOUxNXagvqa43a3d2Zpe8Pbu1gtVILRW29VcvZ4SOk+rbA7q TGpGFe7tlb7v5fKMGc3tMJJvqD+UeLwlJD741K/AMXBRXlJCsMrLiA4UkBDzoamEOD09 0GxB6hRFG0e5oy8wC9F0lQ7eZBBSy/L+qQQqyU4um+/kaZhjBjRCzLjV2+cz2+NtbOIH 2NijUQGrOAxAAFbM7DvsX647ycQ1mFfNPhNrSrL/LYGVokyMTQ4FiGKWTTO1oB6nmzhy qszfYlJJADK8YbYySPwwZBisFrgbXUO4o3hGJcO07h9HgYDAN8RvhXajCqC2jhUtTODL AP2w== X-Gm-Message-State: AGi0Puad9jVRoHbdY5MCSE+I6UZ8/xRSFEiGriCVMP9/L/2y4y4mh+/l oR4NL7SwT1lrjfpqXNqFP15huw== X-Google-Smtp-Source: APiQypIHG237RwAx1qnemv8SrooQSHf6URvb/3jWsAHn+sW8oao73T/wf0UQ5B3Lylcs0W55mcHapw== X-Received: by 2002:ac8:342d:: with SMTP id u42mr5003225qtb.255.1586307614093; Tue, 07 Apr 2020 18:00:14 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:cd27:8edc:808b:771e? ([2601:18b:300:36ee:cd27:8edc:808b:771e]) by smtp.gmail.com with ESMTPSA id v49sm13082059qtv.82.2020.04.07.18.00.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Apr 2020 18:00:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Tue, 7 Apr 2020 21:00:12 -0400 Message-Id: <2B6ED82C-72E8-4659-98DE-835598258D8D@fugue.com> References: <898e18c0-03ec-023c-11e6-3d1fb0e597ec@si6networks.com> Cc: Ole Troan , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters In-Reply-To: <898e18c0-03ec-023c-11e6-3d1fb0e597ec@si6networks.com> To: Fernando Gont X-Mailer: iPhone Mail (17F39) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 01:00:21 -0000 If two addresses are equivalent, why is it a problem to alternate between th= em? > On Apr 7, 2020, at 20:56, Fernando Gont wrote: >=20 > =EF=BB=BFOn 7/4/20 21:02, Ted Lemon wrote: >> It would probably work better to factor preferred lifetimes into source a= ddress selection. iOS, if two source addresses are otherwise equivalent, pic= k the one that=E2=80=99s valid longer. >=20 > Nope. That does not make sense, for two reasons: >=20 > Two routers might be advertising PIOs with different Preferred Lifetimes. A= nd the "algorithm" you'd propose would always pick the address with eh longe= r lifetime, when the specific lifetime value has no intrinsic meaning. >=20 > Then, if your counter-proposal is to prefer "the last advertised PIO", the= n that guarantee that source addresses will flap, which is undesirable. >=20 > In fact, this has been proposed and analyzed. See: https://tools.ietf.org/= html/draft-gont-6man-slaac-renum-06#appendix-B.2 >=20 >=20 >=20 >> This does argue for capping valid lifetimes in RAs. >> We could also sort by time of most recent RA. >=20 > I responded the above before reading this :-) (because we did consider tha= t option). >=20 > Thanks! >=20 > Cheers, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From nobody Tue Apr 7 18:03:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9307B3A104F for ; Tue, 7 Apr 2020 18:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 G63KOUg6dqjC for ; Tue, 7 Apr 2020 18:03:33 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138763A1050 for ; Tue, 7 Apr 2020 18:03:32 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 E1975893DD; Wed, 8 Apr 2020 02:56:37 +0200 (CEST) To: Ted Lemon , Ole Troan Cc: "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters References: <522CDB81-37AE-4D27-B6F3-B3A49B53054D@employees.org> <451C08C9-376F-4275-B8CF-2FD9C194A606@fugue.com> From: Fernando Gont Message-ID: <898e18c0-03ec-023c-11e6-3d1fb0e597ec@si6networks.com> Date: Tue, 7 Apr 2020 21:56:16 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <451C08C9-376F-4275-B8CF-2FD9C194A606@fugue.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 01:03:42 -0000 On 7/4/20 21:02, Ted Lemon wrote: > It would probably work better to factor preferred lifetimes into source address selection. iOS, if two source addresses are otherwise equivalent, pick the one that’s valid longer. Nope. That does not make sense, for two reasons: Two routers might be advertising PIOs with different Preferred Lifetimes. And the "algorithm" you'd propose would always pick the address with eh longer lifetime, when the specific lifetime value has no intrinsic meaning. Then, if your counter-proposal is to prefer "the last advertised PIO", then that guarantee that source addresses will flap, which is undesirable. In fact, this has been proposed and analyzed. See: https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06#appendix-B.2 > This does argue for capping valid lifetimes in RAs. > > We could also sort by time of most recent RA. I responded the above before reading this :-) (because we did consider that option). Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 7 18:46:16 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C31A3A0418 for ; Tue, 7 Apr 2020 18:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spg8MBAitRK1 for ; Tue, 7 Apr 2020 18:46:13 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4FFE3A0416 for ; Tue, 7 Apr 2020 18:46:12 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 2000F893D4; Wed, 8 Apr 2020 03:46:06 +0200 (CEST) To: Ted Lemon Cc: Ole Troan , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters References: <898e18c0-03ec-023c-11e6-3d1fb0e597ec@si6networks.com> <2B6ED82C-72E8-4659-98DE-835598258D8D@fugue.com> From: Fernando Gont Message-ID: <7192826d-0322-8ab5-220e-5c2c2272a98a@si6networks.com> Date: Tue, 7 Apr 2020 22:45:58 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <2B6ED82C-72E8-4659-98DE-835598258D8D@fugue.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 01:46:15 -0000 On 7/4/20 22:00, Ted Lemon wrote: > If two addresses are equivalent, why is it a problem to alternate between them? Undeterministic (PIA to be trouble-shoot) behavour. You try once, it works, you try 1 minute later, it doesn't. To the extent that it's possible, you want to avoid that. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Apr 8 01:06:24 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9633A0C6B for ; Wed, 8 Apr 2020 01:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78vZABgGoBie for ; Wed, 8 Apr 2020 01:06:20 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF11B3A0C6A for ; Wed, 8 Apr 2020 01:06:20 -0700 (PDT) Received: from [10.236.38.154] (77.16.70.154.tmi.telenormobil.no [77.16.70.154]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 671444E11BB1; Wed, 8 Apr 2020 08:06:18 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Wed, 8 Apr 2020 10:06:15 +0200 Message-Id: References: Cc: Ted Lemon , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters In-Reply-To: To: Fernando Gont X-Mailer: iPhone Mail (17E255) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 08:06:23 -0000 Fernando, > On 8 Apr 2020, at 02:56, Fernando Gont wrote: >=20 > =EF=BB=BFOn 7/4/20 20:47, Ole Troan wrote: > [....] >>>=20 >>> It's not perfect, but it way better than what we currently have. (but se= e below). >> It=E2=80=99s a fool=E2=80=99s errand to think you will fix this with shor= t lifetimes. >=20 > It mitigates the problem -- it doesn't eliminate it. >=20 > We have timers. We are just not using them appropriately. What's the point= of having PL and VL lifetimes in a way that they will never go off in any m= eaningful timeframe? No. You are proposing to use the prefix timers for something they were never= designed for.=20 It doesn=E2=80=99t mitigate =E2=80=9Cthe issue=E2=80=9D well enough. We need= to look elsewhere. Cheers=20 Ole >=20 > The PL lifetime could even be reduce to less than the Router Lifetime. At t= he end of the day, that only changes which addresses you'd use for new conne= ctions. If you have another fresher address, that'd me you'd use that addres= s. And if you don't have any other addresses, you'd use the deprectated ones= : they are still valid, and you have no better alternatives. >=20 >=20 >=20 >> Either they are so short that they expire during a link flap or they will= regardless be so long that it=E2=80=99s beyond an acceptable wait time for a= user. >=20 > Please see below. >=20 >=20 >=20 >>>> slaac-renum solves a small corner case of this problem space. >>>=20 >>> slaac-renum mitigates the case described above, *and* also solves in a v= ery efficient and timely manner handle the case where e.g. a CE Router crash= es and reboots. I'm not sure what's your definition of corner-case -- but th= is is a very common scenario. And, as it should be clear from this discussio= n, there are multiple reasons for which such scenarios could take place (CPE= crashes and reboots, CPE announces PIOs with a lifetime that spans past the= DHCPv6-PD lease, etc.) >> Not sure what you mean by the case of a cpe crashing and rebooting and wh= y that should matter. >=20 > Because you receive RAs from the same router that had sent the now stale n= etwork configuration information. Hence, the algorithms from Section 4.5 of d= raft-gont-6man-slaac-renum will deprecate the information in a timely manner= . >=20 > And that's one of the most common scenarios for the problem discussed in d= raft-ietf-v6ops-slaac-renum. >=20 >=20 >=20 >> And may I remind you that ipv6 hosts are used in a diverse set of network= s. >=20 > No need to remind me of that. That has been well considered. >=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 Wed Apr 8 01:32:35 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CC23A0D28 for ; Wed, 8 Apr 2020 01:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBsaYQaHK3kD for ; Wed, 8 Apr 2020 01:32:32 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6007E3A0D24 for ; Wed, 8 Apr 2020 01:32:32 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 1ED7489386; Wed, 8 Apr 2020 10:32:27 +0200 (CEST) To: Ole Troan Cc: Ted Lemon , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters References: From: Fernando Gont Message-ID: Date: Wed, 8 Apr 2020 05:32:07 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 08:32:34 -0000 On 8/4/20 05:06, Ole Troan wrote: > Fernando, > >> On 8 Apr 2020, at 02:56, Fernando Gont wrote: >> >> On 7/4/20 20:47, Ole Troan wrote: >> [....] >>>> >>>> It's not perfect, but it way better than what we currently have. (but see below). >>> It’s a fool’s errand to think you will fix this with short lifetimes. >> >> It mitigates the problem -- it doesn't eliminate it. >> >> We have timers. We are just not using them appropriately. What's the point of having PL and VL lifetimes in a way that they will never go off in any meaningful timeframe? > > No. You are proposing to use the prefix timers for something they were never designed for. 1) I'm proposing to use prefix timers... for timing out timers :-) The Preferred Lifetime, to deprecate an otherwise preferred prefix. The Valid Lifetime, to invalidate the prefix. Just of curiousity, may I ask what do you think they are meant for? (of course, wasting them by using huge values not being a valid option). 2) During the early versions of 6man-slaac-renum, I happened to talk with William Simpson, one of the original authors. He seems to disagree with you. 3) Besides the above to bullets, I'm not sure how "...they were never designed for" becomes a technical argument against the proposal on the table. > It doesn’t mitigate “the issue†well enough. We need to look elsewhere. 6man-slaac-renum contains a number of improvements to mitigate the issue. All of them contribute in a good way towards the ultimate goal. Having insanely long timeouts means you don't even do a bare minimum garbage collection. I don't think we need to look elsewhere. What's in the group of slaac-renum documents does a good job in dealing with the problem we have on the table, in a way that's incrementally deployable and improves the situation without requiring that everyones updates. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Apr 8 01:43:21 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0963A0DB2 for ; Wed, 8 Apr 2020 01:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUs7mxQrc_Is for ; Wed, 8 Apr 2020 01:43:17 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9573A0DAE for ; Wed, 8 Apr 2020 01:43:17 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 3C3BC89386; Wed, 8 Apr 2020 10:43:13 +0200 (CEST) To: Fernando Gont , Ole Troan Cc: Lorenzo Colitti , "v6ops@ietf.org" , Timothy Winters References: From: Fernando Gont Message-ID: <7d48cc76-5cc6-4fb5-1b54-7dc71b933f89@gont.com.ar> Date: Wed, 8 Apr 2020 05:43:07 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 08:43:20 -0000 On 8/4/20 05:32, Fernando Gont wrote: > On 8/4/20 05:06, Ole Troan wrote: >> Fernando, >> >>> On 8 Apr 2020, at 02:56, Fernando Gont wrote: >>> >>> On 7/4/20 20:47, Ole Troan wrote: >>> [....] >>>>> >>>>> It's not perfect, but it way better than what we currently have. >>>>> (but see below). >>>> It’s a fool’s errand to think you will fix this with short lifetimes. >>> >>> It mitigates the problem -- it doesn't eliminate it. >>> >>> We have timers. We are just not using them appropriately. What's the >>> point of having PL and VL lifetimes in a way that they will never go >>> off in any meaningful timeframe? >> >> No. You are proposing to use the prefix timers for something they were >> never designed for. > > 1) I'm proposing to use prefix timers... for timing out timers :-) Of course I meant "timing out prefixes".... -- 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 Apr 8 02:41:24 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677683A0F95 for ; Wed, 8 Apr 2020 02:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8HbaXy1rlp7 for ; Wed, 8 Apr 2020 02:41:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06D53A0F94 for ; Wed, 8 Apr 2020 02:41:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jM7Cf-0000K9C; Wed, 8 Apr 2020 11:41:01 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> In-reply-to: Your message of "Tue, 7 Apr 2020 14:25:53 -0700 ." Date: Wed, 08 Apr 2020 11:40:58 +0200 Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 09:41:22 -0000 >By definition if it is spanning a DHCPv6-PD issued lifetime, it is NOT a = >static prefix. > >What am I missing? DHCPv6-PD is used as a mechanism to populate the FIB of the access router. Just like you can have static IPv4 addresses and still hand them out using DHCPv4. From nobody Wed Apr 8 04:59:51 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC7E3A0795 for ; Wed, 8 Apr 2020 04:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aqwp4FMANao for ; Wed, 8 Apr 2020 04:59:48 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD863A0788 for ; Wed, 8 Apr 2020 04:59:48 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 3E0F18092F; Wed, 8 Apr 2020 13:59:45 +0200 (CEST) To: IPv6 Operations From: Fernando Gont Message-ID: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> Date: Wed, 8 Apr 2020 08:59:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 11:59:51 -0000 Folks, In this recent thread on cpe-slaac-renum, there was a proposal to add text to the draft, and I promised I would start a new thread just in case somebody missed the chance to review in the rather long thread. This text is meant to reflect the comments from Philip, Lorenzo, and others (please do let me know if I misunderstood what you mean). The text is: ---- cut here ---- The Valid Lifetime and Preferred Lifetime of PIOs have direct impact on two different aspects: * The amount of time hosts may end up employing stale network configuration information (see [draft-ietf-v6ops-slaac-renum]). * The amount of time Customer Edge routers would need to persist trying to deprecate stale network configuration information (to handle cases where nodes miss Router Advertisements and thus still consider the stale information as valid). As a result, CPE Routers SHOULD override the default "Preferred Lifetime" and "Valid Lifetime" values from [RFC4861], and employ shorter values to mitigate the aforementioned effect, while complying with the requirement from Section 2.1 of this document, and the recommendations in RFC7772. This document RECOMMENDS that Customer Edge Router set the Router Lifetime and PIO Preferred Lifetime to 2700 seconds (45 minutes) and the PIO Valid Lifetime to 86400 seconds (1 day). We note that a CPE Router need not employ the (possibly long) DHCPv6-PD lease times in the Valid Lifetime and Preferred Lifetime of PIOs sent in Router Advertisements messages to advertise sub-prefixes of the leased prefix. Instead, CPE Routers SHOULD use shorter values for the Valid Lifetime and Preferred Lifetime of PIOs, since subsequent Router Advertisement messages will nevertheless refresh the associated lifetimes, leading to the same effective lifetimes as specified by the DHCPv6-lease time. --- cut here ---- The above change tackles to different issues: * Saner lifetimes that at least allow for proper garbage collection in a timelier manner. * In the typical scenario (but depending on DHCPv6 server parameters), the DHCPv6-PD leased will be longer than the PIO lifetimes advertised by the CE Router, and the CE Router will renew the prefix lease well before the PIO lifetimes need to be adjusted/reduced (to avoid having PIO lifetimes that span past the dhcpv6-pd lease). The result is that, in practice, the CE Routers would send RAs that always contain the same lifetime values, thus avoiding the battery consumption problem mentioned by Lorenzo. Thoughts? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Apr 8 05:54:18 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4858D3A0A01 for ; Wed, 8 Apr 2020 05:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=e-dco-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 pqKBNbWdA4sH for ; Wed, 8 Apr 2020 05:54:15 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377EC3A09F9 for ; Wed, 8 Apr 2020 05:54:15 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id r17so5059945lff.2 for ; Wed, 08 Apr 2020 05:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=1Jjp4A82Pf0weniurb3J5jeEQcMwfNTuJEuwpl8xo98=; b=p9BIM3zZBpYzd4h9rpyj3z9f+4IcpPkL6wuLKg/jKCh/oKVFWS1D+auBTFP02Ue8Vz fPHpm2AlDDcpEXqDQovnFnn/AXrSJcnsZrq1FMtj4iotVi9UTyiRSjKr0i07xytaQr1I /ysgjpdg+9Pet74aEPft8BUXOUzeAMmsLDUguqLqHmfQTIF/sfBELwuIqr17O/Jrr00m +AxiXrtCAYekLVv1RmWSmfkVhHxxORelauDtrnCaX+IRGFkpdZ/sDySP9qodCvuiWN8e 20lQmGQPlZjIK/nvSa3AcCizuSvssYJ4IdHOrxvDrnzHaR34NFCo7EKZkNh4AGGBnlJd sbRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1Jjp4A82Pf0weniurb3J5jeEQcMwfNTuJEuwpl8xo98=; b=nkXbtaz86BCtQ6yvT0oqzySkj2nJjsoB+6iNul5yYcwkRmft45HUvB9D/YgeOpq3pg TuZj12a/1lkwB9/jczXuG6SOh93Yeof2t3J030kkEuOOM6rR/sZ2J73C0EmvE8MCadKT Eu+XB5d8ZfuS7i1rhe9qrp/3dAy3M31facRcAFQ2v9PtO1DNeGQCQV/xZTt5jQJ/26m9 8+dMGVHuMxfqrouPhk4U7PbmE9VCS6CLct/hv6VmwQ9PN8hFHJH47w5HDTn2jPKZAcl9 N4xv17TP03tR/0QeoOTCLQJA5N3bw8iJi9U102tWTdZa7q5fSMMn4Vii3yEQ07K0cegN eRXw== X-Gm-Message-State: AGi0Puad3L4coVPgGKcUiXqptWxaGg6g67o95fH6mOmVSYpsrgBXjpPl k69VqlX8qOjEhA+apJy1oNDNDlGzaCqhhga5FU6np+NIBNOCBw== X-Google-Smtp-Source: APiQypIDxKUPeeix0vGhVlir9iPFnjEATnt1u1Cg/chnoibMziceDctuVXk38Qcd1UG6EDUaHZZuKb9MIzwJ4LmJUSA= X-Received: by 2002:a19:c8cf:: with SMTP id y198mr4265320lff.197.1586350452976; Wed, 08 Apr 2020 05:54:12 -0700 (PDT) MIME-Version: 1.0 From: nalini elkins Date: Wed, 8 Apr 2020 05:54:03 -0700 Message-ID: To: v6ops list Content-Type: multipart/alternative; boundary="0000000000003d3fec05a2c6ff58" Archived-At: Subject: [v6ops] IPv6 Fundamentals Class (for Newbies) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 12:54:17 -0000 --0000000000003d3fec05a2c6ff58 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable New v6Opers, You may be interested in a free class on IPv6 fundamentals funded by a grant from ARIN. This class is aimed at enterprises but may be useful to folks new to v6ops as well. Date: April 16, 2020 Time: Pacific Time 8:00am (UTC 3pm) You may register at: https://attendee.gotowebinar.com/register/274663908000750350 IPv6 training for enterprises is especially pertinent given the Call for Comment on IPv6 for the Federal Government from the U.S. government Office of Management and Budget. Many U.S. based enterprises have network connections to U.S. federal government (Medicare, Federal Reserve, etc.) >From the memo: "Develop an IPv6 implementation plan by the end of FY 2021, and update the Information Resources Management (IRM) Strategic Plan as appropriate, to improve all networked Federal information systems (and the IP-enabled assets associated with these systems) to fully enable native IPv6 operation. The plan shall describe your transition process and include the following milestones and actions: a. At least 20% of IP-enabled assets on Federal networks are IPv6-only by the end of FY 2023; b. At least 50% of IP-enabled assets on Federal networks are IPv6-only by the end of FY 2024; c. At least 80% of IP-enabled assets on Federal networks are IPv6-only by the end of FY 2025; and d. Identify and justify Federal information systems that cannot be converted to use IPv6 and provide a schedule for replacing or retiring these systems; The class description is below. IPv6 Fundamentals Description: To be successful in implementing and understanding IPv6 networks, you need to first understand the IPv6 address methodology which is, in many ways, a fundamental change from the IPv4 paradigm. In this introduction, you will become familiar with what is different as well as what is the same with IPv6. =E2=80=A2 Public and private addresses =E2=80=A2 IPv6 Prefixes =E2=80=A2 IPv6 Address Structure =E2=80=A2 IPv6 Interface ID =E2=80=A2 IPv6 Addressing and Address Allocation Methods (stateless, statef= ull) =E2=80=A2 Address types, unicast, multicast, anycast =E2=80=A2 Address categories: global, site local, link local =E2=80=A2 Unique Local Unicast addresses =E2=80=A2 Zero compression =E2=80=A2 Special addresses (loopback, unspecified, IPv4 mapped IPv6) =E2=80=A2 Broadcast address elimination Neighbor Discovery (SLAAC) Description: The Neighbor Discovery Protocol (NDP) is one of key building blocks of IPv6, though it creates an alphabet soup of acronyms (NDP, RA, RS, NS, NA, DAD, MLD, SLAAC, RDNSS). We will describe how NDP works and its basic functions, including addressing and routing. Network engineers and systems engineers who are familiar with IPv6 addresses are welcome. =E2=80=A2 Neighbor Discovery Protocol (NDP) =E2=80=A2 Router Advertisements (RA) =E2=80=A2 Router Solicitation (RS) =E2=80=A2 Neighbor Solicitation (NS) =E2=80=A2 Neighbor Advertisement (NA) =E2=80=A2 Duplicate Address Detection (DAD) =E2=80=A2 Multicast Listener Discovery (MLD) =E2=80=A2 Stateless Address Autoconfiguration (SLAAC) =E2=80=A2 Router Advertisements for DNS (RDNSS) For our other free webinars, please see: https://industrynetcouncil.org/webinars In particular, you may be interested in a free webinar by Bob Hinden on the History of IPv6. Nalini Elkins --0000000000003d3fec05a2c6ff58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
New v6Opers,

You may be interested in a= free class on IPv6 fundamentals funded by a grant from ARIN.=C2=A0 This cl= ass is aimed at enterprises but may be useful to folks new to v6ops as well= .=C2=A0 =C2=A0 =C2=A0

Date: April 16, 20= 20
Time: Pacific Time 8:00am (UTC 3pm)

Y= ou may register at:=C2=A0
=C2=A0
IPv6 training for enterprises is especially pertinent given the Cal= l for Comment on IPv6 for the Federal Government from the U.S. government O= ffice of Management and Budget.=C2=A0 =C2=A0Many U.S. based enterprises hav= e network=C2=A0connections to U.S.=C2=A0federal government (Medicare, Feder= al Reserve, etc.)

From th= e memo:
=C2=A0
"Develop an IPv6 implementation plan by the end of = FY 2021, and update the Information Resources Management (IRM) Strategic Pl= an=C2=A0as appropriate, to improve all networked Federal information system= s (and the IP-enabled assets associated with these systems) to fully enable= native IPv6 operation.=C2=A0=C2=A0The plan shall describe your transition = process and include the following milestones and actions:

a. At least= 20% of IP-enabled assets on Federal networks are IPv6-only by the end of F= Y 2023;

b. At least 50% of IP-enabled assets on Federal networks are = IPv6-only by the end of FY 2024;

c. At least 80% of IP-enabled assets= on Federal networks are IPv6-only by the end of FY 2025; and
<= div style=3D"color:rgb(0,0,0)">=
d. Identify and justify Federal information systems that cannot be conv= erted to use IPv6 and provide a schedule for replacing or retiring these sy= stems;

The class description is = below.=C2=A0=C2=A0

=C2=A0IPv6 Fundamen= tals

Description: To be successful in implementing and understanding= IPv6 networks, you need to first understand the IPv6 address methodology w= hich is, in many ways, a fundamental change from the IPv4 paradigm. In this= introduction, you will become familiar with what is different as well as w= hat is the same with IPv6.

=E2=80=A2 Public and private addresses=E2=80=A2 IPv6 Prefixes
=E2=80=A2 IPv6 Address Structure
=E2=80=A2 I= Pv6 Interface ID
=E2=80=A2 IPv6 Addressing and Address Allocation Method= s (stateless, statefull)
=E2=80=A2 Address types, unicast, multicast, an= ycast
=E2=80=A2 Address categories: global, site local, link local
= =E2=80=A2 Unique Local Unicast addresses
=E2=80=A2 Zero compression
= =E2=80=A2 Special addresses (loopback, unspecified, IPv4 mapped IPv6)
= =E2=80=A2 Broadcast address elimination

Neighbor Discovery (SLAAC)
Description: The Neighbor Discovery Protocol (NDP) is one of key buil= ding blocks of IPv6, though it creates an alphabet soup of acronyms (NDP, R= A, RS, NS, NA, DAD, MLD, SLAAC, RDNSS). We will describe how NDP works and = its basic functions, including addressing and routing. Network engineers an= d systems engineers who are familiar with IPv6 addresses are welcome.
=E2=80=A2 Neighbor Discovery Protocol (NDP)
=E2=80=A2 Router Advertise= ments (RA)
=E2=80=A2 Router Solicitation (RS)
=E2=80=A2 Neighbor Soli= citation (NS)
=E2=80=A2 Neighbor Advertisement (NA)
=E2=80=A2 Duplica= te Address Detection (DAD)
=E2=80=A2 Multicast Listener Discovery (MLD)<= br>=E2=80=A2 Stateless Address Autoconfiguration (SLAAC)
=E2=80=A2 Route= r Advertisements for DNS (RDNSS)

For our other free webinars, please= see:=C2=A0 https://industrynetcoun= cil.org/webinars=C2=A0

In particular, you may = be interested in a free webinar by Bob Hinden on the History of IPv6.
=

Nalini Elkins
--0000000000003d3fec05a2c6ff58-- From nobody Wed Apr 8 06:54:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34433A0C5F for ; Wed, 8 Apr 2020 06:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=e-dco-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 QvviNqYXbrwl for ; Wed, 8 Apr 2020 06:54:45 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202BA3A0CA1 for ; Wed, 8 Apr 2020 06:54:33 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id g27so7671486ljn.10 for ; Wed, 08 Apr 2020 06:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ahrqypJpVsm3XVliyaaltTAxX0rmhN/UXs4xEHFtN3U=; b=tDsmVoyZOAqi6jQZf1X81RVbFJvjYihWh62XBFr2uyFnJkRsZPy0wsuMbpCzjQRncu YrDQaYq0evQRNuz4Ab8aSmGjKOPrZJIYe9N29ZMyVPpx14nj26FUlKN8IAeAv5rSxfOf oLVTU3fUEsHJv7P2AsQq5AVrvVDwloWzw4kU0YvZdUFu0+mACPVXzZdHVI5nQHOqyOUX wUx8k7X8qLISTCHnzyr/q/E/q8j1GYL8cR5C94oydMXOxg5E43BH8L2CEv/4fCG0zq15 4oSkIvysVuLdEDGGbSB1JVWMoXlZtKlV6M1jRvNZ3GfbmP0/0Xw/a90502tlD2gRZFVm WUCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ahrqypJpVsm3XVliyaaltTAxX0rmhN/UXs4xEHFtN3U=; b=tzZb70b4NX3a1QasyoEzIPpRO88X4NK39NzqeYB9ifV//jVFPaw0Vf0pyMcM98RZWD 84Fjp++fR4s652xw8iBSHJxL7eIwld6Ngsef4YnF5bNIT3LtWN+no1dJ+e7mpTayx+7d NyWlZWFrBfY0p6VIgOhKMDZj09ziVLulPnzZtMkI6pMHYwbu9Fsw2DKsQQCqwDzrIRru NKpKX1zpCnfKN5YSOhbLlUyB0pkMd0FQoiNMtpK7/zY3m/J49NJWWWgk0+ZgNsL3likC ce1RE7kJ0e5s1s9+/bc/IMTO9udPd9TXK4yU+RWP3pOhPg/ocb170QQhUEzefeGJKdHd 8X1w== X-Gm-Message-State: AGi0Pua1lt0iJlrcsSdM3q4dSLHL+iFdVeYWApIW1a8l7Npvd0/+yqEx j/KT4ieyi94QgPAzfPu97ElBIBFcJQDcnNKV4MmiCV0ZSKpscQ== X-Google-Smtp-Source: APiQypJvU7nxQoxToix7nbwdqqXdErIUHHWYpRdmSQdKEeKnm3FsRR2cfV/0Y+XrEL7Iu5y3wg1N30oQHofWcGuP0mw= X-Received: by 2002:a2e:8e3a:: with SMTP id r26mr5169419ljk.233.1586354070840; Wed, 08 Apr 2020 06:54:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: nalini elkins Date: Wed, 8 Apr 2020 06:54:21 -0700 Message-ID: To: v6ops list Content-Type: multipart/alternative; boundary="000000000000e17a8305a2c7d690" Archived-At: Subject: Re: [v6ops] IPv6 Fundamentals Class (for Newbies) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 13:54:48 -0000 --000000000000e17a8305a2c7d690 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Guys, Sorry. Someone told me that the link was not working. Please try this. https://register.gotowebinar.com/register/274663908000750350 Any problems, please let me know. Thanks, Nalini On Wed, Apr 8, 2020 at 5:54 AM nalini elkins wrote: > New v6Opers, > > You may be interested in a free class on IPv6 fundamentals funded by a > grant from ARIN. This class is aimed at enterprises but may be useful to > folks new to v6ops as well. > > Date: April 16, 2020 > Time: Pacific Time 8:00am (UTC 3pm) > > You may register at: > https://attendee.gotowebinar.com/register/274663908000750350 > > IPv6 training for enterprises is especially pertinent given the Call for > Comment on IPv6 for the Federal Government from the U.S. government Offic= e > of Management and Budget. Many U.S. based enterprises have > network connections to U.S. federal government (Medicare, Federal Reserve= , > etc.) > > From the memo: > > "Develop an IPv6 implementation plan by the end of FY 2021, and update th= e > Information Resources Management (IRM) Strategic Plan as appropriate, to > improve all networked Federal information systems (and the IP-enabled > assets associated with these systems) to fully enable native IPv6 > operation. The plan shall describe your transition process and include t= he > following milestones and actions: > > a. At least 20% of IP-enabled assets on Federal networks are IPv6-only by > the end of FY 2023; > > b. At least 50% of IP-enabled assets on Federal networks are IPv6-only by > the end of FY 2024; > > c. At least 80% of IP-enabled assets on Federal networks are IPv6-only by > the end of FY 2025; and > > d. Identify and justify Federal information systems that cannot be > converted to use IPv6 and provide a schedule for replacing or retiring > these systems; > > The class description is below. > > IPv6 Fundamentals > > Description: To be successful in implementing and understanding IPv6 > networks, you need to first understand the IPv6 address methodology which > is, in many ways, a fundamental change from the IPv4 paradigm. In this > introduction, you will become familiar with what is different as well as > what is the same with IPv6. > > =E2=80=A2 Public and private addresses > =E2=80=A2 IPv6 Prefixes > =E2=80=A2 IPv6 Address Structure > =E2=80=A2 IPv6 Interface ID > =E2=80=A2 IPv6 Addressing and Address Allocation Methods (stateless, stat= efull) > =E2=80=A2 Address types, unicast, multicast, anycast > =E2=80=A2 Address categories: global, site local, link local > =E2=80=A2 Unique Local Unicast addresses > =E2=80=A2 Zero compression > =E2=80=A2 Special addresses (loopback, unspecified, IPv4 mapped IPv6) > =E2=80=A2 Broadcast address elimination > > Neighbor Discovery (SLAAC) > > Description: The Neighbor Discovery Protocol (NDP) is one of key building > blocks of IPv6, though it creates an alphabet soup of acronyms (NDP, RA, > RS, NS, NA, DAD, MLD, SLAAC, RDNSS). We will describe how NDP works and i= ts > basic functions, including addressing and routing. Network engineers and > systems engineers who are familiar with IPv6 addresses are welcome. > > =E2=80=A2 Neighbor Discovery Protocol (NDP) > =E2=80=A2 Router Advertisements (RA) > =E2=80=A2 Router Solicitation (RS) > =E2=80=A2 Neighbor Solicitation (NS) > =E2=80=A2 Neighbor Advertisement (NA) > =E2=80=A2 Duplicate Address Detection (DAD) > =E2=80=A2 Multicast Listener Discovery (MLD) > =E2=80=A2 Stateless Address Autoconfiguration (SLAAC) > =E2=80=A2 Router Advertisements for DNS (RDNSS) > > For our other free webinars, please see: > https://industrynetcouncil.org/webinars > > In particular, you may be interested in a free webinar by Bob Hinden on > the History of IPv6. > > Nalini Elkins > --=20 Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com --000000000000e17a8305a2c7d690 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Guys,


Sorry.=C2=A0 Someone told me = that the link was not working.=C2=A0 =C2=A0Please try this.


https://register.gotowebinar.com/register/2746639080007503= 50


Any problem= s, please let me know.


Thanks,

Nalini


On Wed, Apr 8, 2020 at 5:54 AM nalini elkins <nalini.elkins@e-dco.com> wrote:
New v6Opers,<= div>
You may be interested in a free class on IPv6 fundamenta= ls funded by a grant from ARIN.=C2=A0 This class is aimed at enterprises bu= t may be useful to folks new to v6ops as well.=C2=A0 =C2=A0 =C2=A0

Date: April 16, 2020
Time: Pacific Tim= e 8:00am (UTC 3pm)

=C2=A0
IPv6= training for enterprises is especially pertinent given the Call for Commen= t on IPv6 for the Federal Government from the U.S. government Office of Man= agement and Budget.=C2=A0 =C2=A0Many U.S. based enterprises have network=C2= =A0connections to U.S.=C2=A0federal government (Medicare, Federal Reserve, = etc.)

From the memo:
=C2=A0=
&quo= t;Develop an IPv6 implementation plan by the end of FY 2021, and update the= Information Resources Management (IRM) Strategic Plan=C2=A0as appropriate,= to improve all networked Federal information systems (and the IP-enabled a= ssets associated with these systems) to fully enable native IPv6 operation.= =C2=A0=C2=A0The plan shall describe your transition process and include the= following milestones and actions:

a. At least 20% of IP-enabled asse= ts on Federal networks are IPv6-only by the end of FY 2023;

b. At lea= st 50% of IP-enabled assets on Federal networks are IPv6-only by the end of= FY 2024;

c. At least 80% of IP-enabled assets on Federal networks ar= e IPv6-only by the end of FY 2025; and

d. Identify and justify Federa= l information systems that cannot be converted to use IPv6 and provide a sc= hedule for replacing or retiring these systems;

=
The class description is below.=C2=A0=C2=A0
<= br clear=3D"all">
=C2=A0IPv6 Fundamentals

Description: To be suc= cessful in implementing and understanding IPv6 networks, you need to first = understand the IPv6 address methodology which is, in many ways, a fundament= al change from the IPv4 paradigm. In this introduction, you will become fam= iliar with what is different as well as what is the same with IPv6.

= =E2=80=A2 Public and private addresses
=E2=80=A2 IPv6 Prefixes
=E2=80= =A2 IPv6 Address Structure
=E2=80=A2 IPv6 Interface ID
=E2=80=A2 IPv6= Addressing and Address Allocation Methods (stateless, statefull)
=E2=80= =A2 Address types, unicast, multicast, anycast
=E2=80=A2 Address categor= ies: global, site local, link local
=E2=80=A2 Unique Local Unicast addre= sses
=E2=80=A2 Zero compression
=E2=80=A2 Special addresses (loopback= , unspecified, IPv4 mapped IPv6)
=E2=80=A2 Broadcast address elimination=

Neighbor Discovery (SLAAC)

Description: The Neighbor Discove= ry Protocol (NDP) is one of key building blocks of IPv6, though it creates = an alphabet soup of acronyms (NDP, RA, RS, NS, NA, DAD, MLD, SLAAC, RDNSS).= We will describe how NDP works and its basic functions, including addressi= ng and routing. Network engineers and systems engineers who are familiar wi= th IPv6 addresses are welcome.

=E2=80=A2 Neighbor Discovery Protocol= (NDP)
=E2=80=A2 Router Advertisements (RA)
=E2=80=A2 Router Solicita= tion (RS)
=E2=80=A2 Neighbor Solicitation (NS)
=E2=80=A2 Neighbor Adv= ertisement (NA)
=E2=80=A2 Duplicate Address Detection (DAD)
=E2=80=A2= Multicast Listener Discovery (MLD)
=E2=80=A2 Stateless Address Autoconf= iguration (SLAAC)
=E2=80=A2 Router Advertisements for DNS (RDNSS)
For our other free webinars, please see:=C2=A0 https= ://industrynetcouncil.org/webinars=C2=A0

In pa= rticular, you may be interested in a free webinar by Bob Hinden on the Hist= ory of IPv6.

Nalini Elkins


--
Thanks,
Nalini = Elkins
President
Enterprise Data Center Operators

--000000000000e17a8305a2c7d690-- From nobody Wed Apr 8 06:55:51 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30DC3A0C92 for ; Wed, 8 Apr 2020 06:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BdgrLReQDW5 for ; Wed, 8 Apr 2020 06:55:48 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62713A0EDC for ; Wed, 8 Apr 2020 06:55:17 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79d:53aa:d30:2c1f:8a4f:3767:bc85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 903634E11C4D; Wed, 8 Apr 2020 13:55:16 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id A3E563182A0D; Wed, 8 Apr 2020 15:55:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Wed, 8 Apr 2020 15:55:10 +0200 Cc: Ted Lemon , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Fernando Gont X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 13:55:50 -0000 Fernando, >>> We have timers. We are just not using them appropriately. What's the = point of having PL and VL lifetimes in a way that they will never go off = in any meaningful timeframe? >> No. You are proposing to use the prefix timers for something they = were never designed for. >=20 > 1) I'm proposing to use prefix timers... for timing out timers :-) >=20 > The Preferred Lifetime, to deprecate an otherwise preferred prefix. > The Valid Lifetime, to invalidate the prefix. >=20 > Just of curiousity, may I ask what do you think they are meant for? = (of course, wasting them by using huge values not being a valid option). They are meant to support renumbering. > 2) During the early versions of 6man-slaac-renum, I happened to talk = with William Simpson, one of the original authors. He seems to disagree = with you. >=20 > 3) Besides the above to bullets, I'm not sure how "...they were never = designed for" becomes a technical argument against the proposal on the = table. >=20 >=20 >=20 >> It doesn=E2=80=99t mitigate =E2=80=9Cthe issue=E2=80=9D well enough. = We need to look elsewhere. >=20 > 6man-slaac-renum contains a number of improvements to mitigate the = issue. All of them contribute in a good way towards the ultimate goal. >=20 > Having insanely long timeouts means you don't even do a bare minimum = garbage collection. >=20 > I don't think we need to look elsewhere. What's in the group of = slaac-renum documents does a good job in dealing with the problem we = have on the table, in a way that's incrementally deployable and improves = the situation without requiring that everyones updates. slaac-renum tries to solve operational brokenness by tweaking the = protocol. Suggesting all IPv6 implementations should change, and thereby = become more brittle, is not a tradeoff I'm willingto make. What's described in slaac-renum isn't a protocol problem. Ole= From nobody Wed Apr 8 07:00:34 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04CE3A0979 for ; Wed, 8 Apr 2020 07:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SGPCVTQj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0Kfkq9M9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sc2Sr69jxuYH for ; Wed, 8 Apr 2020 07:00:28 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817B13A0C5F for ; Wed, 8 Apr 2020 07:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3676; q=dns/txt; s=iport; t=1586354428; x=1587564028; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vuOExL7TvQ0+pu/7zlkE91uT6vBUFTGeY29M/Yx3V9s=; b=SGPCVTQj6Hh6c0uryYkS4T1OlNa6GfQonb8pjDYaqu790G5rDVGTlDAR HClRGBHiMfOtgWz1V8pmzkJ8hQbPkpgsyUV07i6lim3qfX1qvvJw7jY0I SU05i+tDWd0DBrSeb98BWm3xDHGnNQZG8vPCEPVZYFf5hB8ubVG0sXRp0 g=; IronPort-PHdr: =?us-ascii?q?9a23=3Aayzz5B3iVuz5Q0xPsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGCt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8TgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdCCDV/TJ//xZCt8F8NHBxdo?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAACM141e/4kNJK1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFqAgEBAQELAYFTUAVsWCAECyoKhBKDRQOKa4J?= =?us-ascii?q?fmCCCUgNUCgEBAQwBARgLCgIEAQGERAIXgXAkNwYOAgMBAQsBAQUBAQECAQU?= =?us-ascii?q?EbYVWDIVwAQEBAQIBAQEQEREMAQEsCwEEBwQCAQgRBAEBAwImAgICJQsVCAg?= =?us-ascii?q?CBAENBQgagwWCSwMOIAEOpWQCgTmIYnWBMoJ/AQEFgS8BhAIYgg0DBoEOKgG?= =?us-ascii?q?MMhqCAIFUgk0+gmcBAQKBZYMQMoIskQ2gJwqCPZdSnAiLRIN4nCsCBAIEBQI?= =?us-ascii?q?OAQEFgWgjgVdwFTuCaVAYDZEig3OFFIVBdAKBJ40ZAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.72,358,1580774400"; d="scan'208";a="460307949" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2020 14:00:27 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 038E0RDw004248 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Apr 2020 14:00:27 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 09:00:27 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 10:00:26 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Apr 2020 09:00:26 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SfTYvVdxMo98FLYx6T/OSIKBk+//Ar0eMbDsNM2cBD+JsupUG9KMrMSjRep2zZKyrgMOeOBF/YboFZjpwXF7YOt9NKuOPYj1xe7zhhqmwYThHaLDWlZBcIijhkmytm4WoxHY3Letzj5rgtRA6OQP1OU1kcqgVK1GAHY6SdMpQA8HrZXGcd1F5b9COnY6ajRizUsGNtKje8DWvb6TgOMD1rrqZxqJAueONQemCxOdXXarzlw7pq6Op06t1wd0pNLMq3UO2/0/e+kcDAp2CY84LUmVTdx28Gkehp2IVHqd/MTKjL9EAhP6jAJ3SHPbZwlAMZV4dr62LeFuXTETkjf19Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vuOExL7TvQ0+pu/7zlkE91uT6vBUFTGeY29M/Yx3V9s=; b=hLFWfmmLsMiEPSIhuOaNiXM8f3J5ge3AldaF57cyckvJmtPS8y6S0dRGGKQ8U+0g7I3z5Eq6DRfxq+9pR/siHOUqONq+Ifimp30UqTS5bGXj5kodUESNPnPmOWFRgWTLe+i6JbH65jX5FGaHnLct5EYbYb+xQ3QlTfcVVXBtUDowSYgjiFacXDgBlK9qwagdt745aST01jZkI7BQxIuMPD28GJf4vCFzhTrLR7jm97zBDrUkL9uJ9vkrao4546xywPRLJOvlDC11YrVte/zHNXM2DNZLw+OY2FSiujChEuHd0giUOgxQCqWYXzEckiIR4rZaahDEhxatHWH97al7Bg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vuOExL7TvQ0+pu/7zlkE91uT6vBUFTGeY29M/Yx3V9s=; b=0Kfkq9M9gti/jaxNlLtP3sbT5Bx+ToB++brakeACiPHac3lJRx0Ge+Y+4t/NPvDYRvBMcRwq3r0Vrlto5BR4ck9uRK65gpn+jA0mXwy9JBKKjpuQqzzuibZc0AfkTOkjPxc69qEIvl4wjcYk6Uh9EZQYr7tuwq+h/YQPxdbf/NA= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2818.namprd11.prod.outlook.com (2603:10b6:406:ad::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Wed, 8 Apr 2020 14:00:25 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Wed, 8 Apr 2020 14:00:25 +0000 From: "Bernie Volz (volz)" To: "otroan@employees.org" , Fernando Gont CC: Lorenzo Colitti , "v6ops@ietf.org" , Timothy Winters Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdYGqnrRGOoD4f0yRz2uh9FnYboxrQFa48mAABGxD4AAIZyHgAAAR/kAAAAZVQAAAH4QAAAAyxqAABKBFYAAALpDgAABhtwAAA/oCoAAAOdEgAALSEsAAAAdYnA= Date: Wed, 8 Apr 2020 14:00:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8813cbe8-d96f-44f2-b546-08d7dbc52fb4 x-ms-traffictypediagnostic: BN7PR11MB2818: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4125; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(366004)(136003)(39860400002)(346002)(396003)(53546011)(8676002)(9686003)(478600001)(966005)(110136005)(33656002)(86362001)(55016002)(81156014)(4326008)(54906003)(2906002)(316002)(66946007)(71200400001)(8936002)(7696005)(5660300002)(186003)(76116006)(81166007)(66476007)(52536014)(6506007)(26005)(66446008)(64756008)(66556008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oA8NnyOd+8RvgtMdQpJQOUnaHmFqFYkyJm3MYZE+knfj0kkz+x0WsjAmx73umwb2qQq5BBUFFnggbdFLZvnHg43DWvqwniZ87z0gyX/Of0F1yYAxUAifLiJzzW4pEgh32irMDh/G/3BV7fkEkpMv+HQRmTZARM4TUWxa0YiyBNMpVDJLmZ0dfznK3fl18hBsrg80T+bV6Ibk3soJtgmubkulNvHlPR8Mb1IJF8xqEF6ReTBLlAIvWHXjK1vLwp7PmncRqiza1M5AURyXUQvrjeeiYaz7fHT8xgEvhzhDlje/Qi+pgDhJfUbHoQiV9C/I6fg//E+thMu3HJBLdya3G6VWtanD30QvLn+3r5cB/4O1B7wrmV7czmo9rB+1nT9WgPY+VdAzTGA9zTN4DTWywxOa3Kzly6n5CPsQn51PqyYLatMO+4eNyWI/kVCMD8S9tIFn3u+RsOh8phMz189YULS5AtD+RgCuHUKZBW3gAL+Vtwa59t01Iw3qVTKue27tXJGkElgifjaFIg6WFF3RUg== x-ms-exchange-antispam-messagedata: duJ7VmVDyx34Atvxmpuajx+HiP3MYAM43pgIaWuoSZ8zu+vS+v6wxJjQXLrBLJHYzveJEBerlypVQadW+LsZBKCorCoDv2j2iJQ5ZgM33trHHB0MgxPRSqKB7aodeBsxp9hByfjGqsZux2LEr4bnaA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8813cbe8-d96f-44f2-b546-08d7dbc52fb4 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 14:00:25.0557 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7wlrwaleJbFCPWv+1XDmA1mxrD1mYQxEpHDBobivWw0q/NcMpHdtDSCTokHppLeH X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2818 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 14:00:32 -0000 PldoYXQncyBkZXNjcmliZWQgaW4gc2xhYWMtcmVudW0gaXNuJ3QgYSBwcm90b2NvbCBwcm9ibGVt Lg0KDQpBbmQsIGlzbid0IHRoYXQgd2h5IGl0IGlzIGluIHY2b3BzPyBEaXNjdXNzaW5nIGxpZmV0 aW1lIHZhbHVlcyBpcyBhbiBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9uOyB0aGUgcHJvdG9jb2wg YWxyZWFkeSBwcm92aWRlcyBmb3Igc3VwcG9ydGluZyB3aGF0ZXZlciBsaWZldGltZXMgYXJlIHNl bGVjdGVkIChwcm92aWRlZCB0aGV5IG1lZXQgdGhlIHByb3RvY29sIHJlcXVpcmVtZW50cyBzdWNo IGFzIHByZWZlcnJlZCA8PXZhbGlkLCAuLi4pLg0KDQotIEJlcm5pZQ0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBvdHJvYW5AZW1wbG95ZWVzLm9yZw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA4LCAy MDIwIDk6NTUgQU0NClRvOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+DQpD YzogTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz47 IHY2b3BzQGlldGYub3JnOyBUaW1vdGh5IFdpbnRlcnMgPHR3aW50ZXJzQGlvbC51bmguZWR1Pg0K U3ViamVjdDogUmU6IFt2Nm9wc10gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtdjZvcHMtY3Bl LXNsYWFjLXJlbnVtDQoNCkZlcm5hbmRvLA0KDQo+Pj4gV2UgaGF2ZSB0aW1lcnMuIFdlIGFyZSBq dXN0IG5vdCB1c2luZyB0aGVtIGFwcHJvcHJpYXRlbHkuIFdoYXQncyB0aGUgcG9pbnQgb2YgaGF2 aW5nIFBMIGFuZCBWTCBsaWZldGltZXMgaW4gYSB3YXkgdGhhdCB0aGV5IHdpbGwgbmV2ZXIgZ28g b2ZmIGluIGFueSBtZWFuaW5nZnVsIHRpbWVmcmFtZT8NCj4+IE5vLiBZb3UgYXJlIHByb3Bvc2lu ZyB0byB1c2UgdGhlIHByZWZpeCB0aW1lcnMgZm9yIHNvbWV0aGluZyB0aGV5IHdlcmUgbmV2ZXIg ZGVzaWduZWQgZm9yLg0KPiANCj4gMSkgSSdtIHByb3Bvc2luZyB0byB1c2UgcHJlZml4IHRpbWVy cy4uLiBmb3IgdGltaW5nIG91dCB0aW1lcnMgOi0pDQo+IA0KPiBUaGUgUHJlZmVycmVkIExpZmV0 aW1lLCB0byBkZXByZWNhdGUgYW4gb3RoZXJ3aXNlIHByZWZlcnJlZCBwcmVmaXguDQo+IFRoZSBW YWxpZCBMaWZldGltZSwgdG8gaW52YWxpZGF0ZSB0aGUgcHJlZml4Lg0KPiANCj4gSnVzdCBvZiBj dXJpb3VzaXR5LCBtYXkgSSBhc2sgd2hhdCBkbyB5b3UgdGhpbmsgdGhleSBhcmUgbWVhbnQgZm9y PyAob2YgY291cnNlLCB3YXN0aW5nIHRoZW0gYnkgdXNpbmcgaHVnZSB2YWx1ZXMgbm90IGJlaW5n IGEgdmFsaWQgb3B0aW9uKS4NCg0KVGhleSBhcmUgbWVhbnQgdG8gc3VwcG9ydCByZW51bWJlcmlu Zy4NCg0KPiAyKSBEdXJpbmcgdGhlIGVhcmx5IHZlcnNpb25zIG9mIDZtYW4tc2xhYWMtcmVudW0s IEkgaGFwcGVuZWQgdG8gdGFsayB3aXRoIFdpbGxpYW0gU2ltcHNvbiwgb25lIG9mIHRoZSBvcmln aW5hbCBhdXRob3JzLiBIZSBzZWVtcyB0byBkaXNhZ3JlZSB3aXRoIHlvdS4NCj4gDQo+IDMpIEJl c2lkZXMgdGhlIGFib3ZlIHRvIGJ1bGxldHMsIEknbSBub3Qgc3VyZSBob3cgIi4uLnRoZXkgd2Vy ZSBuZXZlciBkZXNpZ25lZCBmb3IiIGJlY29tZXMgYSB0ZWNobmljYWwgYXJndW1lbnQgYWdhaW5z dCB0aGUgcHJvcG9zYWwgb24gdGhlIHRhYmxlLg0KPiANCj4gDQo+IA0KPj4gSXQgZG9lc27igJl0 IG1pdGlnYXRlIOKAnHRoZSBpc3N1ZeKAnSB3ZWxsIGVub3VnaC4gV2UgbmVlZCB0byBsb29rIGVs c2V3aGVyZS4NCj4gDQo+IDZtYW4tc2xhYWMtcmVudW0gY29udGFpbnMgYSBudW1iZXIgb2YgaW1w cm92ZW1lbnRzIHRvIG1pdGlnYXRlIHRoZSBpc3N1ZS4gQWxsIG9mIHRoZW0gY29udHJpYnV0ZSBp biBhIGdvb2Qgd2F5IHRvd2FyZHMgdGhlIHVsdGltYXRlIGdvYWwuDQo+IA0KPiBIYXZpbmcgaW5z YW5lbHkgbG9uZyB0aW1lb3V0cyBtZWFucyB5b3UgZG9uJ3QgZXZlbiBkbyBhIGJhcmUgbWluaW11 bSBnYXJiYWdlIGNvbGxlY3Rpb24uDQo+IA0KPiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gbG9v ayBlbHNld2hlcmUuIFdoYXQncyBpbiB0aGUgZ3JvdXAgb2Ygc2xhYWMtcmVudW0gZG9jdW1lbnRz IGRvZXMgYSBnb29kIGpvYiBpbiBkZWFsaW5nIHdpdGggdGhlIHByb2JsZW0gd2UgaGF2ZSBvbiB0 aGUgdGFibGUsIGluIGEgd2F5IHRoYXQncyBpbmNyZW1lbnRhbGx5IGRlcGxveWFibGUgYW5kIGlt cHJvdmVzIHRoZSBzaXR1YXRpb24gd2l0aG91dCByZXF1aXJpbmcgdGhhdCBldmVyeW9uZXMgdXBk YXRlcy4NCg0Kc2xhYWMtcmVudW0gdHJpZXMgdG8gc29sdmUgb3BlcmF0aW9uYWwgYnJva2VubmVz cyBieSB0d2Vha2luZyB0aGUgcHJvdG9jb2wuIFN1Z2dlc3RpbmcgYWxsIElQdjYgaW1wbGVtZW50 YXRpb25zIHNob3VsZCBjaGFuZ2UsIGFuZCB0aGVyZWJ5IGJlY29tZSBtb3JlIGJyaXR0bGUsIGlz IG5vdCBhIHRyYWRlb2ZmIEknbSB3aWxsaW5ndG8gbWFrZS4NCldoYXQncyBkZXNjcmliZWQgaW4g c2xhYWMtcmVudW0gaXNuJ3QgYSBwcm90b2NvbCBwcm9ibGVtLg0KDQpPbGUNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QN CnY2b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQo= From nobody Wed Apr 8 07:10:10 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071813A0CB4 for ; Wed, 8 Apr 2020 07:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRNrERwZqfpp for ; Wed, 8 Apr 2020 07:10:06 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E1F3A0CA7 for ; Wed, 8 Apr 2020 07:10:05 -0700 (PDT) Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 89C824E11B0A; Wed, 8 Apr 2020 14:10:05 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 35E563183846; Wed, 8 Apr 2020 16:09:58 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Wed, 8 Apr 2020 16:09:57 +0200 Cc: Fernando Gont , Lorenzo Colitti , "v6ops@ietf.org" , Timothy Winters Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bernie Volz X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 14:10:08 -0000 >> What's described in slaac-renum isn't a protocol problem. >=20 > And, isn't that why it is in v6ops? Discussing lifetime values is an = operational consideration; the protocol already provides for supporting = whatever lifetimes are selected (provided they meet the protocol = requirements such as preferred <=3Dvalid, ...). As explained earlier using prefix timers to affect routing doesn't work = well. For fast convergence the timers need to be so short, so that the = addresses will not survive a link-flap, or even the shortes of hiccups = in the access link. Too long and convergence is so slow that the user gives up. Plus of course the multitude of other cases where this does not solve = the problem. This proposal also ignores all the correct deployments of PD, where the = operator honours the lifetimes he sets and wants the hosts to have = access to those lifetimes. addressing !=3D routing. Ole From nobody Wed Apr 8 07:12:54 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025A63A0CA8 for ; Wed, 8 Apr 2020 07:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l-ygFRPHRF0 for ; Wed, 8 Apr 2020 07:12:42 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D23E3A0E28 for ; Wed, 8 Apr 2020 07:12:01 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 384F380049; Wed, 8 Apr 2020 16:11:56 +0200 (CEST) To: otroan@employees.org Cc: Ted Lemon , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters References: From: Fernando Gont Message-ID: <9593bb1a-001a-0ec8-712b-9dff80373838@si6networks.com> Date: Wed, 8 Apr 2020 11:11:48 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 14:12:45 -0000 On 8/4/20 10:55, otroan@employees.org wrote: > Fernando, > >>>> We have timers. We are just not using them appropriately. What's the point of having PL and VL lifetimes in a way that they will never go off in any meaningful timeframe? >>> No. You are proposing to use the prefix timers for something they were never designed for. >> >> 1) I'm proposing to use prefix timers... for timing out timers :-) >> >> The Preferred Lifetime, to deprecate an otherwise preferred prefix. >> The Valid Lifetime, to invalidate the prefix. >> >> Just of curiousity, may I ask what do you think they are meant for? (of course, wasting them by using huge values not being a valid option). > > They are meant to support renumbering. Part of renumbering is phasing out prefixes. And this is what we are doing here. >> 6man-slaac-renum contains a number of improvements to mitigate the issue. All of them contribute in a good way towards the ultimate goal. >> >> Having insanely long timeouts means you don't even do a bare minimum garbage collection. >> >> I don't think we need to look elsewhere. What's in the group of slaac-renum documents does a good job in dealing with the problem we have on the table, in a way that's incrementally deployable and improves the situation without requiring that everyones updates. > > slaac-renum tries to solve operational brokenness by tweaking the protocol. Suggesting all IPv6 implementations should change, and thereby become more brittle, Certainly the opposite: A network is really brittle if just because a CPE Router crashes and reboots, the network breaks. slaac-renum improves robustness. Even in the presence of cheap CPE, things do work. I have no idea how you could possibly consider a network to be robust when in order for things to work, a lot of things need to happened in the way you expect, and a lot of elements you don't even have control of, need to function perfectly well. A core design principle of the Internet is that as long as there is a working path from source to destination, communications survive possible outages. > is not a tradeoff I'm willingto make. > What's described in slaac-renum isn't a protocol problem. I respect that you may have a different opinion and disagree. Now, splitting your role as a participant, and your role as wg char, may we have a wg call on draft-gont-6man-slaac-renum at 6man? 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 Apr 8 07:14:30 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91843A0FBC for ; Wed, 8 Apr 2020 07:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMTbcfTi46uq for ; Wed, 8 Apr 2020 07:14:20 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD6D3A0D47 for ; Wed, 8 Apr 2020 07:14:14 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 B150E8056D; Wed, 8 Apr 2020 16:14:11 +0200 (CEST) To: "Bernie Volz (volz)" , "otroan@employees.org" Cc: "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters References: From: Fernando Gont Message-ID: <4be72340-1333-3648-64e2-916404d5fd3f@si6networks.com> Date: Wed, 8 Apr 2020 11:13:58 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 14:14:28 -0000 On 8/4/20 11:00, Bernie Volz (volz) wrote: >> What's described in slaac-renum isn't a protocol problem. > > And, isn't that why it is in v6ops? Discussing lifetime values is an operational consideration; the protocol already provides for supporting whatever lifetimes are selected (provided they meet the protocol requirements such as preferred <=valid, ...). I *think* Ole is referring to one of the three documents on the topic, draft-gont-6man-slaac-renum, targetted at 6man, that contains protocol updates. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Apr 8 07:29:33 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A114E3A0DBE for ; Wed, 8 Apr 2020 07:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=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 KT383QPrwKy5 for ; Wed, 8 Apr 2020 07:29:30 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664F43A0DC6 for ; Wed, 8 Apr 2020 07:29:30 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79d:53aa:d30:2c1f:8a4f:3767:bc85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 0BBC64E11B0D; Wed, 8 Apr 2020 14:29:29 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 113713184172; Wed, 8 Apr 2020 16:29:16 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: <9593bb1a-001a-0ec8-712b-9dff80373838@si6networks.com> Date: Wed, 8 Apr 2020 16:29:15 +0200 Cc: Ted Lemon , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters Content-Transfer-Encoding: quoted-printable Message-Id: References: <9593bb1a-001a-0ec8-712b-9dff80373838@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 14:29:32 -0000 >>>>> We have timers. We are just not using them appropriately. What's = the point of having PL and VL lifetimes in a way that they will never go = off in any meaningful timeframe? >>>> No. You are proposing to use the prefix timers for something they = were never designed for. >>>=20 >>> 1) I'm proposing to use prefix timers... for timing out timers :-) >>>=20 >>> The Preferred Lifetime, to deprecate an otherwise preferred prefix. >>> The Valid Lifetime, to invalidate the prefix. >>>=20 >>> Just of curiousity, may I ask what do you think they are meant for? = (of course, wasting them by using huge values not being a valid option). >> They are meant to support renumbering. >=20 > Part of renumbering is phasing out prefixes. And this is what we are = doing here. No you are not. If you were doing renumbering, then you'd get two prefixes in DHCP PD. = One old expired (lifetimes 0), one new with lifetimes > 0. If that simple operational rule was followed, then none of these tweaks = are required. (At least for this purpose). >>> 6man-slaac-renum contains a number of improvements to mitigate the = issue. All of them contribute in a good way towards the ultimate goal. >>>=20 >>> Having insanely long timeouts means you don't even do a bare minimum = garbage collection. >>>=20 >>> I don't think we need to look elsewhere. What's in the group of = slaac-renum documents does a good job in dealing with the problem we = have on the table, in a way that's incrementally deployable and improves = the situation without requiring that everyones updates. >> slaac-renum tries to solve operational brokenness by tweaking the = protocol. Suggesting all IPv6 implementations should change, and thereby = become more brittle,=20 >=20 > Certainly the opposite: A network is really brittle if just because a = CPE Router crashes and reboots, the network breaks. >=20 > slaac-renum improves robustness. Even in the presence of cheap CPE, = things do work. >=20 > I have no idea how you could possibly consider a network to be robust = when in order for things to work, a lot of things need to happened in = the way you expect, and a lot of elements you don't even have control = of, need to function perfectly well. >=20 > A core design principle of the Internet is that as long as there is a = working path from source to destination, communications survive possible = outages. Oh, I'm not saying that we shouldn't make host behaviour more robust. = Rather the contrary. I'm just saying I don't think the proposed changes = are the right ones. Let me see if I find some spare time to write down how I would like it = to work. Don't hold your breath. >> is not a tradeoff I'm willingto make. >> What's described in slaac-renum isn't a protocol problem. >=20 > I respect that you may have a different opinion and disagree. >=20 > Now, splitting your role as a participant, and your role as wg char, = may we have a wg call on draft-gont-6man-slaac-renum at 6man? If you want me to put my chair hat on, then you need to take that to the = 6man list. Cheers, Ole= From nobody Wed Apr 8 07:36:14 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929773A0CE9 for ; Wed, 8 Apr 2020 07:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=mQaMKMI5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=AdbVM5VF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC9pYwanvP0B for ; Wed, 8 Apr 2020 07:36:10 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BE73A0B54 for ; Wed, 8 Apr 2020 07:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1722; q=dns/txt; s=iport; t=1586356570; x=1587566170; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qyGot03r66KJlYOtXByqGFr/KBM0qRfRFDEqK+R9yPs=; b=mQaMKMI5/TJWzRDL/UG3ReW9PbL6BPMssr/sjGhcc/4h3DHRge0hemVj enLLLQ9I/QEYKxe4vlNGdmAvKOs7rVxpLIN0w0lUpul9OeK9pT/lbygYB kWBJ9Ol+TuBLEIiCyeSyOIMKTfzQ88X9CHNUCP24c2iWbXbmu+XNlLdeM 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AqPQbKB1RRjQa53amsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGCt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8TgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdCCDV/TJ//xZCt8F8NHBxdo?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAAAi4Y1e/4QNJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBagMBAQELAYFTUAWBRCAECyoKhBKDRQOKa4JfmCCBQoE?= =?us-ascii?q?QA1QKAQEBDAEBLQIEAQGERAIXgXAkNwYOAgMBAQsBAQUBAQECAQUEbYVWDIV?= =?us-ascii?q?wAQEBAQMSEREMAQE3AQsEAgEIDgMEAQEBAgImAgICMBUICAIEAQ0FCBqFUAM?= =?us-ascii?q?uAaVtAoE5iGJ1gTKCfwEBBYU8GIINCYEOKgGMMhqCAIFUgk0+hBkBEgEjgxA?= =?us-ascii?q?ygiyRDaAnCoI9l1KcCItEg3icKwIEAgQFAg4BAQWBaCM3MHBwFTuCaVAYDZE?= =?us-ascii?q?ig3OKVXSBKY0ZAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.72,358,1580774400"; d="scan'208";a="754813660" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2020 14:36:00 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 038Ea0Lo022575 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Apr 2020 14:36:00 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 09:36:00 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 10:35:59 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Apr 2020 10:35:59 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IRAZo6+BHa7CsHsTELYR3Xk5QhKmsMcNhB52uilwgC/7BRcCeG2wuhoJtNVJSpLptIoWKGxgN18uRpY+IhrUhUNt3HFS4OMqo+IxoG0FCjsdKu6H+hMTwJYTOAxM6H+M9EjcZsKnPFvUYOHvHP91YnTE4uSQUJm3hsWwjUfRdkQIN6Jm/JCZ36i/QOFosvVmL9fX+pifWG0oz2J3EVdIxYPxXPa5uOL3JcUOtwrNoO1LfpdkP+YDv8etgchprt/nNwIvQkBqIJ+z3OawzkYQkPcTHJBeD9So1pqzutH0o7smVRIv+eWgwxbzbf/7pWxhhwFhiRlCZrm4LH4QqrZu/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qyGot03r66KJlYOtXByqGFr/KBM0qRfRFDEqK+R9yPs=; b=fgRg0hCvQWjmfpfAL9FCQzQ2BYWriFE637/1XsJl+R3qW82aGdCs8h0qVkFZGvBOeqf71dHORTQDUihFg9ceNtRT7IWUJ3bl/a80TjNtNAlOclM0XsUtmJns4VyIGnTFMEssGr76yJqmHHAv9DdhVYSpv06wakkPfpHb5uS5KKC5XaMZycH2F5t3QTzhI1EqnwbA1A0NLzGWmcR/yuk16OXiI7tWZgvTecRJ7o8GmtYf85CMzNOBnfU9Z7OdDy6WlwuLFlGWUU5E1BPT25c1YKNDa27R8DcqNk0LQvLeL4kklNspfdbtmHZSelz4fnXbJScqQyFfmgH2RKIkeByK/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qyGot03r66KJlYOtXByqGFr/KBM0qRfRFDEqK+R9yPs=; b=AdbVM5VF9IiLydZXsFRlmKACWqOeSJf/ryjrNelO77Tm2ypIrYOw6YZ+uYFdl+Sm3gvVKSwK+8GxyIHNDa3BILS2gIfFOLbxXRzRHibk82OdxCnAl9PgsQdH0wK/bOqG9T1YxdsxSVXDF1ywXnnbPKRXM0oWrJDfVTGaGu7QIiM= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2562.namprd11.prod.outlook.com (2603:10b6:406:b4::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Wed, 8 Apr 2020 14:35:57 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Wed, 8 Apr 2020 14:35:57 +0000 From: "Bernie Volz (volz)" To: Fernando Gont , "otroan@employees.org" CC: "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdYGqnrRGOoD4f0yRz2uh9FnYboxrQFa48mAABGxD4AAIZyHgAAAR/kAAAAZVQAAAH4QAAAAyxqAABKBFYAAALpDgAABhtwAAA/oCoAAAOdEgAALSEsAAAAdYnAAAIq0AAAAtcoQ Date: Wed, 8 Apr 2020 14:35:57 +0000 Message-ID: References: <4be72340-1333-3648-64e2-916404d5fd3f@si6networks.com> In-Reply-To: <4be72340-1333-3648-64e2-916404d5fd3f@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3df5bf2b-7039-4a6a-b011-08d7dbca26ba x-ms-traffictypediagnostic: BN7PR11MB2562: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(366004)(136003)(346002)(396003)(39860400002)(7696005)(54906003)(86362001)(33656002)(71200400001)(8676002)(53546011)(6506007)(478600001)(186003)(66476007)(9686003)(66556008)(52536014)(26005)(2906002)(76116006)(5660300002)(66946007)(81166007)(81156014)(66446008)(8936002)(4326008)(64756008)(55016002)(110136005)(316002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1uwLX7hh+m1H+wy9rhE2GoT3BGEPdMcpvzE9dcxQo4q9pzUeFlyc8+17K581DCTMSbhGhV9s4Oz8r7skz41QelqQn02olM6w4yxcA2rqCECOEVVXTYT3/732RxNSWFKdma+/2L4YrHLK4ZfB4RQ0zdNRC3mgJd4NfYqbwGCIWxCwi/QXkUbkBaoIX/Yl5FLTBPH2PMVTPM0VorOedZ6X3S6gtrOF69CXo8z0n4ilA/WcabOY2bnVWUVQt/H8eSZL7ubTyd7T2EbN+tm+SNoCqDitYnlOBD6Mb3Yf3xACt9Acu10f+Q6d/dmYg8YMBpDaLQARLE/rCDEd/QjGMO4IXOl8tA7RTg9C4KHL9iVg6sE53L5fb6nHWR5DFSJs0XqJz1bK9nYmxBBq+fx4mvxEUXiz8LjZdrMKX7LD/UTVS3Mz4JEWZ+VjVLUzCn7bBkH+ x-ms-exchange-antispam-messagedata: 1auKsCxKxwMQ0QEDP1d15hBjSx3Wem0ioSIF2mtm+3kZvBo+doOtXQ4TPUmZtqpuAi1Jnba7sTo2ybsWW4kRzRATo4IicRZ9GpLFMKSoYr7DFx2fta+V1VTMYawisXow7gyv8WqjDO4/7VZ37JmUNw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3df5bf2b-7039-4a6a-b011-08d7dbca26ba X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 14:35:57.4880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /2b0W0O87yP1RuK2o0b2bchDXm4Z1rY9RGU49robTE6NNv38fY8REQ4t4/xWIlrv X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2562 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 14:36:13 -0000 WWVhaCAuLiBpdCB3YXMgYnVyaWVkIGluIHRoZSB0ZXh0IGFuZCBlYXN5IHRvIG1pc3MgLi4uIHRo ZSBTdWJqZWN0IGlzIHY2b3BzIGFuZCB0aGUgbGlzdCB3YXMgdjZvcHMsIHNvIEkgdGhvdWdodCBp dCB3YXMgaW4gcmVmZXJlbmNlIHRvIHRoYXQgYW5kIGdsYW5jZWQgb3ZlciB0aGUgIjZtYW4iIGlu IHRoZSBkb2N1bWVudCBpbiB0aGUgdGV4dC4NCg0KRml4ZWQgVGltJ3MgZW1haWwgYWRkcmVzcy4N Cg0KLSBCZXJuaWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEZlcm5hbmRv IEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNvbT4gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDgs IDIwMjAgMTA6MTQgQU0NClRvOiBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28uY29tPjsg b3Ryb2FuQGVtcGxveWVlcy5vcmcNCkNjOiB2Nm9wc0BpZXRmLm9yZzsgTG9yZW56byBDb2xpdHRp IDxsb3JlbnpvQGdvb2dsZS5jb20+OyBUaW1vdGh5IFdpbnRlcnMgPHR3aW50ZXJzQGlvbC51bmgu ZWR1Pg0KU3ViamVjdDogUmU6IFt2Nm9wc10gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtdjZv cHMtY3BlLXNsYWFjLXJlbnVtDQoNCk9uIDgvNC8yMCAxMTowMCwgQmVybmllIFZvbHogKHZvbHop IHdyb3RlOg0KPj4gV2hhdCdzIGRlc2NyaWJlZCBpbiBzbGFhYy1yZW51bSBpc24ndCBhIHByb3Rv Y29sIHByb2JsZW0uDQo+IA0KPiBBbmQsIGlzbid0IHRoYXQgd2h5IGl0IGlzIGluIHY2b3BzPyBE aXNjdXNzaW5nIGxpZmV0aW1lIHZhbHVlcyBpcyBhbiBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9u OyB0aGUgcHJvdG9jb2wgYWxyZWFkeSBwcm92aWRlcyBmb3Igc3VwcG9ydGluZyB3aGF0ZXZlciBs aWZldGltZXMgYXJlIHNlbGVjdGVkIChwcm92aWRlZCB0aGV5IG1lZXQgdGhlIHByb3RvY29sIHJl cXVpcmVtZW50cyBzdWNoIGFzIHByZWZlcnJlZCA8PXZhbGlkLCAuLi4pLg0KDQpJICp0aGluayog T2xlIGlzIHJlZmVycmluZyB0byBvbmUgb2YgdGhlIHRocmVlIGRvY3VtZW50cyBvbiB0aGUgdG9w aWMsIGRyYWZ0LWdvbnQtNm1hbi1zbGFhYy1yZW51bSwgdGFyZ2V0dGVkIGF0IDZtYW4sIHRoYXQg Y29udGFpbnMgcHJvdG9jb2wgdXBkYXRlcy4NCg0KDQotLQ0KRmVybmFuZG8gR29udA0KU0k2IE5l dHdvcmtzDQplLW1haWw6IGZnb250QHNpNm5ldHdvcmtzLmNvbQ0KUEdQIEZpbmdlcnByaW50OiA2 NjY2IDMxQzYgRDQ4NCA2M0IyIDhGQjEgRTNDNCBBRTI1IDBENTUgMUQ0RSA3NDkyDQoNCg0KDQoN Cg== From nobody Wed Apr 8 07:52:54 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567DF3A0E09 for ; Wed, 8 Apr 2020 07:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 xVUd852e_OU4 for ; Wed, 8 Apr 2020 07:52:51 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA803A0DFD for ; Wed, 8 Apr 2020 07:52:51 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 99F3C804D1; Wed, 8 Apr 2020 16:52:47 +0200 (CEST) To: Ted Lemon , otroan@employees.org Cc: "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters References: <1ACD1488-4B70-47C0-B543-FB6CE5F526C1@fugue.com> From: Fernando Gont Message-ID: <700d5ff4-4e1d-b426-80b8-a88638c2a9ec@si6networks.com> Date: Wed, 8 Apr 2020 11:43:00 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <1ACD1488-4B70-47C0-B543-FB6CE5F526C1@fugue.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 14:52:54 -0000 On 8/4/20 11:19, Ted Lemon wrote: [....] > > Having the host keep a prefix around for a month in the absence of a single RA during that month seems like nonsensical behavior. > > If the prefix is to be valid for a month, presumably communication will be occurring frequently during that month; if it is not, then in what sense is the prefix valid? > > What is the motivation for such long lifetimes?. Not sure about the motivation. But it makes as much sense as putting an setting a clock alarm to wake up 2000 years from now. :-) -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Apr 8 07:57:47 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFAC3A0D50 for ; Wed, 8 Apr 2020 07:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Y4QMu88o; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=X37PUdKR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeprEEjty1dM for ; Wed, 8 Apr 2020 07:57:43 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E3253A0D31 for ; Wed, 8 Apr 2020 07:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3993; q=dns/txt; s=iport; t=1586357863; x=1587567463; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6jZaz7gUJSfk8z4kVm+eGkhwINWcgAyiM/u786nbpis=; b=Y4QMu88oGds+AyS91UrlB8MCKY9CbJhTM0q5kZgTprxlwMLSm8RQ70D8 /5MpF67nbpOtiA6TUvfheRyPJKiIeuOtGVv8Ci1uut5PKYheqWajvx3Lu uYoWuSWyd2Sk+hJ6yM5cSGKdXcJij6NKZEBE1I87DLLQMt8J7NwAsc5ep E=; IronPort-PHdr: =?us-ascii?q?9a23=3ATYIJgBwZ7g/RDKHXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YRGN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A+GsHbIQKUh?= =?us-ascii?q?YEjcsMmAl1HsmBG2XwLeXhaGoxG8ERHFI=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAAAp5Y1e/5ldJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWgGAQELAYFTUAVsWCAECyoKh1cDimtOghGYIIEugSQDVAoBAQE?= =?us-ascii?q?MAQEYCwoCBAEBhEQCggckNQgOAgMBAQsBAQUBAQECAQUEbYVWDIVwAQEBAQM?= =?us-ascii?q?BARAoBgEBLAwLBAIBCA4DBAEBHxAnCx0IAgQBEggagwWCSwMuAQ6lZAKBOYh?= =?us-ascii?q?igieCfwEBBYEvAYQMGIINAwaBOAGMMhqCAIFUgk0+gmcBAYEiKxqDQoIsjW8?= =?us-ascii?q?fk0CPZgqCPZdSgk6IOpEAiwc9g3icKwIEAgQFAg4BAQWBUwE3gVdwFTuCaVA?= =?us-ascii?q?YDZEig3OFFIVBdIEpjRkBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.72,358,1580774400"; d="scan'208";a="499721106" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2020 14:57:41 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 038Evf4i004641 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Apr 2020 14:57:41 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 09:57:41 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 09:57:40 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Apr 2020 09:57:40 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NI2hPSEtyaSfG3mW3WwTrEzh+6QLG7YovVIsfF2QKh9AqWBulxp+DVHTov1KjxeY/xE9PKMZZGVOda3tklMnsq0OuQsUPW2vlIOrrUbzikERHvr9HLDviLGuXnpn4UHa+5+JEVrT5aliqJckoC8kzYspkGC4Ok9NNMPBum/uBBuFOsYqGli+pEBRTqCffGlD+NvETCGcRTXqILXIoMzcZIzKNYT5SFEAfuU473Mt9tFYF7lFJgxbwrIEhDKZkfWcY2gtOGKVE9Y6uCa5e+2MkeaIAC2+BsWUizE/R+CNBBq4uZzmteRiv9FrcIobYHPZ1JINwXbxeeUz8sfux/RFzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6jZaz7gUJSfk8z4kVm+eGkhwINWcgAyiM/u786nbpis=; b=laiIywHO1eBaUUtDPhKsn+PQQmr+WPXPtxCos/mEk07OCba+sboHB79d9yEwIbvTjsNKTx6ppNwGGCi7i6OcAU9jaPmZcOreJDzXockzOvEarnO7nslyiPsifbEkZmaHscXcuQkPb1xTzR0SvBIWJlSmYrVjhnonhJ7INeAY+chN0bwLbH0zgaEjnS+0nYOox+UpptskzQYoY/p/V9cvRkvjthCAYurqbzJkTifQuyDfrcPeW7cqckNCnfPwqAVzhA3JZei5qGRxUtjC06aw8DLyDsv4yJPn69KJlmrZm9RUP2pSbOQpFZtXAvMZZxdzLSk9xeJMUhHp4ODBuEqDlg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6jZaz7gUJSfk8z4kVm+eGkhwINWcgAyiM/u786nbpis=; b=X37PUdKR9X3tSAg+2Ji3A7VC+XCgzvpsRg8rnEcoeAhzP0s7r5weWXOM+ogE6/cGeosgdoY7q3qXpQcfpXpmFQVXtjnCSCrn93VTqc+ZFq2EKB0I1TSLIbf69849aokVSWF0wiyAErcFO95hDETJ1wm/DJeg6ay+NDQMHmedHdA= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2707.namprd11.prod.outlook.com (2603:10b6:406:ac::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Wed, 8 Apr 2020 14:57:39 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Wed, 8 Apr 2020 14:57:39 +0000 From: "Bernie Volz (volz)" To: Fernando Gont , IPv6 Operations Thread-Topic: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes Thread-Index: AQHWDZ1XwKMiAc+bXU6k0lDVbIJuY6hvTjSg Date: Wed, 8 Apr 2020 14:57:39 +0000 Message-ID: References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> In-Reply-To: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f47359c7-ef36-4ef2-06c8-08d7dbcd2e9f x-ms-traffictypediagnostic: BN7PR11MB2707: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(346002)(396003)(376002)(39860400002)(366004)(5660300002)(110136005)(71200400001)(966005)(316002)(55016002)(66574012)(52536014)(8936002)(76116006)(8676002)(81156014)(186003)(26005)(66476007)(66946007)(86362001)(7696005)(478600001)(9686003)(66556008)(53546011)(33656002)(81166007)(64756008)(66446008)(2906002)(6506007); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XEXQGpE4x/E4pa0Yqo+UV5iz1paTdM0jGbE+CQrKATOePFUuhbSUXuhev2MiW1hKE7LXL5i7Dkf9V9vHxJyEkCwzcFXIkuZEm5hyfn2m6J0L2SF0akRxBlxcwDEyo1dBoW0eWRtYJIUa3BaUzZ6rIjZu72dAnihDG/4ltAZO928g4DRqcjvYWTvJm4UmjKEBtfdLysc1dBjMkoPLgi4m9lKHDy1wd0+Otmwef7Myt7lYJrm8x6xbSQemcHSH6PCdGLeMer5xyFW7EnLbEKOxnDqO1bz3pG22aUQr1GZtXVDy8UE3hb42QYQEGGwbTT/n6Z21g4jnDWwuzycnXq9SkiAPYjynkLe2UhUSw1pVBz2CoO3/3uAs9rZ0fc+w/sMtSI/D9Vbxd2YQpjfgmIwmmDl/lgoPc5bLQ6UPUgohLyz9+bJBZMWcOL69OdRehK059RvIbMzlsM1UrwOEfQ7pqQKE3dvnF5eVReYQp51gh8F4yy5Ii2GG4/y2f5iqjv/5hL+N6sUUnsbR/0PlDaogBQ== x-ms-exchange-antispam-messagedata: RwK8kn6R0KRqb5HtRi+Zl0GKZgom+SYyQn+brU41zX1bGrLnr+1HW2rhfV6YORuu7Laa0gbiH+msAGJANsjPApJ1pT7Dsj3LwkSFwWNqFfRknujvQonJB4JBN8c3WIfITvyguEVxUdrthCs8k78xyQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f47359c7-ef36-4ef2-06c8-08d7dbcd2e9f X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 14:57:39.2267 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: H7olXlIXVbdml02/Ixubh5JLyGM5SwSxxcVRFXqPrFnAEDuzIYrLOCaahwZTbFhn X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2707 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 14:57:46 -0000 A few comments: 1. One reason to cap the lifetime(s) in the CPE for RAs is that while the S= P could adjust the lifetimes, that has a direct impact on the amount of DHC= Pv6 traffic as reducing the preferred lifetime will cause the renewals to o= ccur more frequently. That is one reason why SPs do not use short preferred= lifetimes. (Some SPs have many millions of CPEs.) 2. I do wonder whether leaving the valid lifetime alone is better than play= ing with both lifetimes. For most applications that don't require long live= d addresses, it achieves the desired effect. For those that want long lived= addresses, it allows for that (if case of outages longer than the capped v= alid lifetime) -- and if the application decides to try for a new address, = it will use one in a new prefix if one was advertised. - Bernie=20 -----Original Message----- From: v6ops On Behalf Of Fernando Gont Sent: Wednesday, April 8, 2020 8:00 AM To: IPv6 Operations Subject: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes Folks, In this recent thread on cpe-slaac-renum, there was a proposal to add text = to the draft, and I promised I would start a new thread just in case somebo= dy missed the chance to review in the rather long thread. This text is meant to reflect the comments from Philip, Lorenzo, and others= (please do let me know if I misunderstood what you mean). The text is: ---- cut here ---- The Valid Lifetime and Preferred Lifetime of PIOs have direct impact on two= different aspects: * The amount of time hosts may end up employing stale network configuration= information (see [draft-ietf-v6ops-slaac-renum]). * The amount of time Customer Edge routers would need to persist trying to = deprecate stale network configuration information (to handle cases where no= des miss Router Advertisements and thus still consider the stale informatio= n as valid). As a result, CPE Routers SHOULD override the default "Preferred Lifetime" a= nd "Valid Lifetime" values from [RFC4861], and employ shorter values to mit= igate the aforementioned effect, while complying with the requirement from = Section 2.1 of this document, and the recommendations in RFC7772. This docu= ment RECOMMENDS that Customer Edge Router set the Router Lifetime and PIO P= referred Lifetime to 2700 seconds (45 minutes) and the PIO Valid Lifetime t= o 86400 seconds (1 day). We note that a CPE Router need not employ the (possibly long) DHCPv6-PD lea= se times in the Valid Lifetime and Preferred Lifetime of PIOs sent in Route= r Advertisements messages to advertise sub-prefixes of the leased prefix. I= nstead, CPE Routers SHOULD use shorter values for the Valid Lifetime and Pr= eferred Lifetime of PIOs, since subsequent Router Advertisement messages wi= ll nevertheless refresh the associated lifetimes, leading to the same effec= tive lifetimes as specified by the DHCPv6-lease time. --- cut here ---- The above change tackles to different issues: * Saner lifetimes that at least allow for proper garbage collection in a ti= melier manner. * In the typical scenario (but depending on DHCPv6 server parameters), the = DHCPv6-PD leased will be longer than the PIO lifetimes advertised by the CE= Router, and the CE Router will renew the prefix lease well before the PIO = lifetimes need to be adjusted/reduced (to avoid having PIO lifetimes that s= pan past the dhcpv6-pd lease). The result is that, in practice, the CE Rout= ers would send RAs that always contain the same lifetime values, thus avoid= ing the battery consumption problem mentioned by Lorenzo. Thoughts? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Apr 8 08:09:42 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C663A0E3A for ; Wed, 8 Apr 2020 08:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 lTTelaDnypLF for ; Wed, 8 Apr 2020 08:09:38 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82BFB3A13C9 for ; Wed, 8 Apr 2020 08:08:32 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 E5AE4893D3; Wed, 8 Apr 2020 16:52:52 +0200 (CEST) To: otroan@employees.org Cc: Ted Lemon , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters References: <9593bb1a-001a-0ec8-712b-9dff80373838@si6networks.com> From: Fernando Gont Message-ID: Date: Wed, 8 Apr 2020 11:51:39 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 15:09:40 -0000 On 8/4/20 11:29, otroan@employees.org wrote: >>>>>> We have timers. We are just not using them appropriately. What's the point of having PL and VL lifetimes in a way that they will never go off in any meaningful timeframe? >>>>> No. You are proposing to use the prefix timers for something they were never designed for. >>>> >>>> 1) I'm proposing to use prefix timers... for timing out timers :-) >>>> >>>> The Preferred Lifetime, to deprecate an otherwise preferred prefix. >>>> The Valid Lifetime, to invalidate the prefix. >>>> >>>> Just of curiousity, may I ask what do you think they are meant for? (of course, wasting them by using huge values not being a valid option). >>> They are meant to support renumbering. >> >> Part of renumbering is phasing out prefixes. And this is what we are doing here. > > No you are not. Let's agree to disagree. I put a timer for addresses. Unless there's any sort of signal that the configuration is current in a veeery reasonable period of time, I phase out the prefix. > If you were doing renumbering, then you'd get two prefixes in DHCP PD. One old expired (lifetimes 0), one new with lifetimes > 0. This was already discussed on this mailing list. Please read draft-ietf-v6ops-slaac-renum. Many operators have already spoke up on the topic. I don't have much to add in addition to what has already been said. > If that simple operational rule was followed, then none of these tweaks are required. (At least for this purpose). If folks had follow the simple operational plan that everyone enables v6, and then when everyone could simply disable IPv4, we would have deployed v6 20 years ago, and we wouldn't have the ..load of transition/co-existence mechanisms that we have. But hey, engineering is a bit about solving problems in the real world, rather than complaining that the problems are not solvable because the planet should actually be spinning in the opposite direction. >> A core design principle of the Internet is that as long as there is a working path from source to destination, communications survive possible outages. > > Oh, I'm not saying that we shouldn't make host behaviour more robust. Rather the contrary. I'm just saying I don't think the proposed changes are the right ones. > Let me see if I find some spare time to write down how I would like it to work. Don't hold your breath. We have been discussing this problem for over one year now. > >>> is not a tradeoff I'm willingto make. >>> What's described in slaac-renum isn't a protocol problem. >> >> I respect that you may have a different opinion and disagree. >> >> Now, splitting your role as a participant, and your role as wg char, may we have a wg call on draft-gont-6man-slaac-renum at 6man? > > If you want me to put my chair hat on, then you need to take that to the 6man list. I did, indeed: https://mailarchive.ietf.org/arch/msg/ipv6/qO_vGJrDVMOC1fnOGa8DquONOAs/ (at least for the second time). 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 Apr 8 08:12:37 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661DF3A0B64 for ; Wed, 8 Apr 2020 08:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc2IqdsJ3b5V for ; Wed, 8 Apr 2020 08:12:33 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C8C3A0B59 for ; Wed, 8 Apr 2020 08:12:33 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 61D77803F8; Wed, 8 Apr 2020 17:12:31 +0200 (CEST) To: "Bernie Volz (volz)" , IPv6 Operations References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> From: Fernando Gont Message-ID: Date: Wed, 8 Apr 2020 12:12:21 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 15:12:36 -0000 On 8/4/20 11:57, Bernie Volz (volz) wrote: [...] > 1. One reason to cap the lifetime(s) in the CPE for RAs is that while the SP could adjust the lifetimes, that has a direct impact on the amount of DHCPv6 traffic as reducing the preferred lifetime will cause the renewals to occur more frequently. That is one reason why SPs do not use short preferred lifetimes. (Some SPs have many millions of CPEs.) Agreed. Maybe one might add a sentence about this? > 2. I do wonder whether leaving the valid lifetime alone is better than playing with both lifetimes. For most applications that don't require long lived addresses, it achieves the desired effect. For those that want long lived addresses, it allows for that (if case of outages longer than the capped valid lifetime) -- and if the application decides to try for a new address, it will use one in a new prefix if one was advertised. Reality is that, once you have an outage of over 15', all your TCP sessions will be aborted, anyway. So having long valid lifetimes will not buy you anything in that respect. In that sense, you'd be well enough with a Valid Lifetime of 2 * Router Lifetime. The reason why we left the Valid Lifetime to a rather long value (1 day) is mainly for the case where you want to use such prefix for local communications. However, strictly speaking, you should be using link-locals for that (but I realize there are issues associated with the fact that they require an interface to be specified along with the address) or, better, you should be using ULAs. I guess, if one wanted a finer-grained recommendation, one might unfold the recommendation for GUAs vs. ULAs. With GUAs, you want more timely information. With ULAs, you don't really care that much, because it's local addressing (isolated from your ISP). Going back to your orignal comment: if you don't do garbage collection (i.e. reasonable Valid Lifetime) on your prefixes/addresses, then that means you wouldn't be able to communicate with the new "owner"/user of the prefix -- because you consider that prefix to be local/on-link. I'm not saying that I think there's a lot of chances that you might need/want to communicate with the new user of the prefix. But if for some reason (plain bad luck? :-) ) you needed, then you couldn't. (that's why you don't want one-month valid lifetimes for PIOs) 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 Apr 8 08:25:44 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62003A0E9E for ; Wed, 8 Apr 2020 08:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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 6dTz8pa9EWsa for ; Wed, 8 Apr 2020 08:25:40 -0700 (PDT) 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 9245B3A074B for ; Wed, 8 Apr 2020 08:25:38 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id 130so465303qke.4 for ; Wed, 08 Apr 2020 08:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Gz6uv50cEspvJ8RitOqkVwbI9QWbhnLeIdJaarnSuYY=; b=G+5q5npvj+/URrHSlexHtOaJHi/rvr0z7bcuVnPkPnNbnCyxUwTC70YG6oQVSW+IUM u/YD8dJ/UY587UFWaV6vxS3z/N4UCucu6QDGVnCSs/CO1jclv1/jDGcWcOyBZqmdrMMo GRHGCIcAeF/2XnJWLn4RHPPnx9raM86lMVYJqUavpGFXqECk9I4i/hmjoDkPNGCVTFWk TMJk1xAwqdPZma0NiGB1mpO9Zi8Gr1rQE3hgmq4A9F42oa1NLNDvuDZCWfdvmNxaDx2m LOJ6/b3yJY3b0kr7dWMEoHptir+DPu4upWxWOPNSDtGB0AlrfAbDJbmFDzp+/KrbQMSk 9/qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Gz6uv50cEspvJ8RitOqkVwbI9QWbhnLeIdJaarnSuYY=; b=Ia/iG+xEVJt+g7KD5yM28jtpW731JM/yY1FbYWr2C0LV6nyrncrHcZiL/u6SNXrcJ9 XnjVzsT0NzC9LN1/2Nw+5WfJ9RCLwTv1im1J9HInYwWAdtZu6tJBys68p7jAeZ5xzqsG gBRFEPtJB08IwrQri1hqH99eeEUUyaPX7xbiXS3y71ZvmEDVCiqxfodWJRpa4tWDL3Rf tMn9m2qLPX6as9iZkY73W36i0XtiAYD188JOX8Df1vSNGamm7hctgH8TxB9hZ7+Y02bD mXRZNzE/j3KLphqCpdobanR+PDdSFD5pAsQWYurzz0jyL+RqshTPK17TGjBzDnLz+aLn Wx7Q== X-Gm-Message-State: AGi0PuYZAG85Pqf0+gJ0/anrgtubsodCPZKt4OBU1YJRxZx/sOWIfIQ3 LGxxZ9nJvDt/y9rjAzjkssKPqPAHlTY= X-Google-Smtp-Source: APiQypIjUd2dIqIaxfJRvo5RYKLQ3kqmXPTB3YGDhkQl5SdYOk9HSTRYiURVT4oicq/pvbWiCvZYCw== X-Received: by 2002:a37:7d81:: with SMTP id y123mr7029146qkc.102.1586355589487; Wed, 08 Apr 2020 07:19:49 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:201b:83ea:1756:69e4? ([2601:18b:300:36ee:201b:83ea:1756:69e4]) by smtp.gmail.com with ESMTPSA id i13sm12161464qtj.37.2020.04.08.07.19.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Apr 2020 07:19:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 8 Apr 2020 10:19:48 -0400 Message-Id: <1ACD1488-4B70-47C0-B543-FB6CE5F526C1@fugue.com> References: Cc: Fernando Gont , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters In-Reply-To: To: otroan@employees.org X-Mailer: iPad Mail (17E255) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 15:25:42 -0000 On Apr 8, 2020, at 9:55 AM, otroan@employees.org wrote: >=20 > They are meant to support renumbering. Ole, isn=E2=80=99t that exactly what we=E2=80=99re discussing here? I think you=E2=80=99re holding to the rather narrow definition of renumberin= g as something that is in the control of the ISP, and so therefore anticipat= ing the possibility of a renumbering event that is not in the control of the= ISP seems out of scope. But the reality is that the =E2=80=9Coperator=E2=80=9D here is the CPE gatew= ay, not the ISP. The CPE gateway may have multiple upstream connections. I= t can=E2=80=99t necessarily assume that promises made by the upstream will b= e kept. And so anticipating the possibility of a renumbering event and keep= ing timers short enough that they can be expired reasonably quickly in the e= vent of an actual renumbering event, while keeping them long enough that the= y don=E2=80=99t flap, seems like a reasonable thing for a CPE to do. Having the host keep a prefix around for a month in the absence of a single R= A during that month seems like nonsensical behavior. If the prefix is to be= valid for a month, presumably communication will be occurring frequently du= ring that month; if it is not, then in what sense is the prefix valid? What is the motivation for such long lifetimes?= From nobody Wed Apr 8 08:51:26 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A247B3A0BDD for ; Wed, 8 Apr 2020 08:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=N9cPQ2Np; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=M/xNPxuk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMjl1puOPnJ6 for ; Wed, 8 Apr 2020 08:51:22 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A413A0BD9 for ; Wed, 8 Apr 2020 08:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3486; q=dns/txt; s=iport; t=1586361082; x=1587570682; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zqc4Pw5A9yQg/JN/UBSZPazM0m5iht4Hol7AOA0hrts=; b=N9cPQ2NpMwsFe4Bpw3L/w2jCydxZW3PFEJxdIKxzxSS3GaMdgCavWTDt XJ7yx28COHSAYQRwLODdnWJ6QBDqRduomy4RXLCfKT56qQrbM4Xb7YYei hohjOZseP6oCO7ocNyP7JnpXwucDsku2k4krR++utXrH0I4VK6v0aFS+Q k=; IronPort-PHdr: =?us-ascii?q?9a23=3A9Y3E8RBxkn0DtUH9tdfrUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qgw3kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMdRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFP8KOzCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAABZ8o1e/5JdJa1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgWgDAQEBAQELAYFTKScFbFggBAsqCoQ?= =?us-ascii?q?Sg0UDimuCX5gggS4UgRADVAoBAQEMAQEYCwoCBAEBhEQCF4FwJDUIDgIDAQE?= =?us-ascii?q?LAQEFAQEBAgEFBG2FVgyFcAEBAQEDAQEQEREMAQEsCwELBAIBCA4DBAEBAQI?= =?us-ascii?q?CJgICAiULFQgIAgQBDQUIGoI5TIJLAy4BDqVsAoE5iGJ1gTKCfwEBBYEvAYQ?= =?us-ascii?q?LGIINAwaBDioBjDIaggCBEUOCTT6CZwEBAoElJhqDEDKCLI4GgweIbZc6CoI?= =?us-ascii?q?9l1KcCItEg3icKwIEAgQFAg4BAQWBVAE2gVdwFTuCaVAYDZEigScBCYJChRS?= =?us-ascii?q?FQXQCgSeNGQEwXwEB?= X-IronPort-AV: E=Sophos;i="5.72,359,1580774400"; d="scan'208";a="469628330" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2020 15:51:21 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 038FpL7v007047 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Apr 2020 15:51:21 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 10:51:21 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 10:51:21 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Apr 2020 10:51:21 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F/7e4AUAANVVKwpr7l9kByHsaEKbWaKpCGxAwQDuQiq1t4RAJBw1pDhoCFOX7HNgdn/Rm913ys5ZVCLJiAjCEZ0YkGw9m+Q4MaD+wUyW5WkR4kpaFXdtxzl9M92krl7HTtvMjdsLl+kRp5fSSfvcPTKqx93R5gFNTU1RxtxDS3qLop0fJzbwJN/OHCIWJQ0wCFkhadP4ouMX9QSPDrw63aESba0d+F2nubGrqv/O1vO8ExEmK1nbneKDwiq2kU3UmFuZ97a2FwS+SVZPQ3vGJ9vWayKhAEb0srI/EgBZ/IUSF4F7fnzaDe1KlwZwpo/1Vqq/xrlheUm63555T/R1qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zqc4Pw5A9yQg/JN/UBSZPazM0m5iht4Hol7AOA0hrts=; b=EHI0zdXy89vxTGbFqHuE7IeIOIXMsybS+JD8DYXmrVvAz2Wwu2SVkkuvFc3tgdFqAsCcj+5xDBaLnDBahonhJ3XaR6rLYJBpzLf13ZnYvJe8KTuZzy/rANL9SG4KuD9y3pOjQlwfx2GxMPuDzkeGN8N3kNSJhETLmGVkr2vMxZuIrBzcjNhSlBSiPxs5DosSjgRV16onXc7Go7KCjFRUWTOI1i6zsUGrk6z2XpoGpMer/4llxtLiCSIfONkVdmZk3D6Pt9felwP+Rv0pvHDQJpVvxNYqvYPC3xZMeaa5iqzo7c4tRjVmx6ke71Kj40A8UEdGLmkcoT1PWORktJHGYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zqc4Pw5A9yQg/JN/UBSZPazM0m5iht4Hol7AOA0hrts=; b=M/xNPxukx62ELhnCXpMlWxxS24rr+oe3jKivT+YV+yB2ujEEvuuyBKL2fiF3MCoOv8dNUdO1zFEKkTbF3XBrLXH/Tu5DfFHO208iAlKthsZtNi9/+QHliCNaswS4tNvCbWk0XkZ0VYc+fsDcetan5YaJAbRs+DSkUUL7tlv8jPo= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2722.namprd11.prod.outlook.com (2603:10b6:406:b8::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Wed, 8 Apr 2020 15:51:19 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Wed, 8 Apr 2020 15:51:19 +0000 From: "Bernie Volz (volz)" To: Ted Lemon , "otroan@employees.org" CC: Fernando Gont , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdYGqnrRGOoD4f0yRz2uh9FnYboxrQFa48mAABGxD4AAIZyHgAAAR/kAAAAZVQAAAH4QAAAAyxqAABKBFYAAALpDgAABhtwAAA/oCoAAAOdEgAALSEsAAADcPQAAAyFzQA== Date: Wed, 8 Apr 2020 15:51:19 +0000 Message-ID: References: <1ACD1488-4B70-47C0-B543-FB6CE5F526C1@fugue.com> In-Reply-To: <1ACD1488-4B70-47C0-B543-FB6CE5F526C1@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6eabfa5e-3258-46b2-3e2d-08d7dbd4ae42 x-ms-traffictypediagnostic: BN7PR11MB2722: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(39860400002)(346002)(396003)(136003)(366004)(110136005)(2906002)(478600001)(966005)(76116006)(71200400001)(316002)(7696005)(8676002)(81166007)(186003)(54906003)(4326008)(55016002)(86362001)(6506007)(53546011)(66946007)(66446008)(26005)(52536014)(66476007)(66556008)(8936002)(81156014)(64756008)(9686003)(5660300002)(33656002)(66574012); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Tef86hie3XPqt2AD/wtkOOL3JwRW/OkW3ze3cjwRUSPrLjr48blqm5Xxk46I5EIiHwsvljxFGEPy/KLLIOrs9fBbO9HQ+WC4Ptx9HSvdyj0/FYG6ZH3q5QXQb5T4xDwkP9gzAV+e3v7GjQJaklGlpo+RCbIv2OZ9oHq4KqRbUl54IFFVMTRplL49DUwkChhNZIcHCYbqVDdMftDTusHcULoTccWTMJspwMuePYXzSGXJA9h8yWwl0hXAl1Xn9Rfj8hLsnzH2znhOcFUuo9qDcmsdO0VOeONO5F0akFRA7xXNqxCsdZZSvDMloY9aiml6+VgbLZenvVqvZ4BpGsenV0EaegnQzHp44nOlr7mssB5mDAnz6e+EHUtl851F+/45K77XPE88kuqtImxyiFZNThqSQa+ij/sg7rsINlHo1jCpM4s+PAoMkggHaCxv1VMb6xDwqfQldM0HuQiq+NhT68G+aXBMzf7dK4GwMj3P1S+tDdIlh2TobE91Qktbv2KI7x1c8U3qBzbcCkPWc6R6Gg== x-ms-exchange-antispam-messagedata: k5mCj1lGEoJ28igkEazNKPr+a2ry5VatazCtaxhJ63AG0zAk444MZfIXXCD/XhLJIXcJqHmhrTA8ZmkBejnhXoz/uZ59anSNpvZpSymd7z4jUN3GU6TyqkYTkz9iQjKMy8bcVnxIVubUS7DbZ0fMIA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6eabfa5e-3258-46b2-3e2d-08d7dbd4ae42 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 15:51:19.7182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fS3OnwZJecuaZjLrbsEPAQLCBuVDhJjbgjn4/PeIRKfXxABHeGDKaahzIxrX/HP4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2722 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 15:51:25 -0000 QW5kLCB0aGVyZSBpcyBub3RoaW5nIHRoYXQgcmVxdWlyZXMgUEQgdG8gdXNlIHRoZSBsaWZldGlt ZXMgcmVjZWl2ZWQgZnJvbSB0aGUgREhDUCBzZXJ2ZXIgaW4gcm91dGVyIGFkdmVydGlzZW1lbnRz Lg0KDQpSRkM4NDE1IGhhczoNCg0KICAgSWYgdGhlIGNsaWVudCB1c2VzIGEgZGVsZWdhdGVkIHBy ZWZpeCB0byBjb25maWd1cmUgYWRkcmVzc2VzIG9uDQogICBpbnRlcmZhY2VzIG9uIGl0c2VsZiBv ciBvdGhlciBub2RlcyBiZWhpbmQgaXQsIHRoZSBwcmVmZXJyZWQgYW5kDQogICB2YWxpZCBsaWZl dGltZXMgb2YgdGhvc2UgYWRkcmVzc2VzIE1VU1QgYmUgbm8gbG9uZ2VyIHRoYW4gdGhlDQogICBy ZW1haW5pbmcgcHJlZmVycmVkIGFuZCB2YWxpZCBsaWZldGltZXMsIHJlc3BlY3RpdmVseSwgZm9y IHRoZQ0KICAgZGVsZWdhdGVkIHByZWZpeCBhdCBhbnkgdGltZS4gIEluIHBhcnRpY3VsYXIsIGlm IHRoZSBkZWxlZ2F0ZWQgcHJlZml4DQogICBvciBhIHByZWZpeCBkZXJpdmVkIGZyb20gaXQgaXMg YWR2ZXJ0aXNlZCBmb3Igc3RhdGVsZXNzIGFkZHJlc3MNCiAgIGF1dG9jb25maWd1cmF0aW9uIFtS RkM0ODYyXSwgdGhlIGFkdmVydGlzZWQgcHJlZmVycmVkIGFuZCB2YWxpZA0KICAgbGlmZXRpbWVz IE1VU1QgTk9UIGV4Y2VlZCB0aGUgY29ycmVzcG9uZGluZyByZW1haW5pbmcgbGlmZXRpbWVzIG9m DQogICB0aGUgZGVsZWdhdGVkIHByZWZpeC4NCg0KU28sIHRoZSBsaWZldGltZXMgY2FuIGJlIHNo b3J0ZXIuDQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2 Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFRlZCBMZW1vbg0KU2Vu dDogV2VkbmVzZGF5LCBBcHJpbCA4LCAyMDIwIDEwOjIwIEFNDQpUbzogb3Ryb2FuQGVtcGxveWVl cy5vcmcNCkNjOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+OyB2Nm9wc0Bp ZXRmLm9yZzsgTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRm Lm9yZz47IFRpbW90aHkgV2ludGVycyA8dHdpbnRlcnNAaW9sLnVuaC5lZHU+DQpTdWJqZWN0OiBS ZTogW3Y2b3BzXSBXRyBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi12Nm9wcy1jcGUtc2xhYWMtcmVu dW0NCg0KT24gQXByIDgsIDIwMjAsIGF0IDk6NTUgQU0sIG90cm9hbkBlbXBsb3llZXMub3JnIHdy b3RlOg0KPiANCj4gVGhleSBhcmUgbWVhbnQgdG8gc3VwcG9ydCByZW51bWJlcmluZy4NCg0KT2xl LCBpc27igJl0IHRoYXQgZXhhY3RseSB3aGF0IHdl4oCZcmUgZGlzY3Vzc2luZyBoZXJlPw0KDQpJ IHRoaW5rIHlvdeKAmXJlIGhvbGRpbmcgdG8gdGhlIHJhdGhlciBuYXJyb3cgZGVmaW5pdGlvbiBv ZiByZW51bWJlcmluZyBhcyBzb21ldGhpbmcgdGhhdCBpcyBpbiB0aGUgY29udHJvbCBvZiB0aGUg SVNQLCBhbmQgc28gdGhlcmVmb3JlIGFudGljaXBhdGluZyB0aGUgcG9zc2liaWxpdHkgb2YgYSBy ZW51bWJlcmluZyBldmVudCB0aGF0IGlzIG5vdCBpbiB0aGUgY29udHJvbCBvZiB0aGUgSVNQIHNl ZW1zIG91dCBvZiBzY29wZS4NCg0KQnV0IHRoZSByZWFsaXR5IGlzIHRoYXQgdGhlIOKAnG9wZXJh dG9y4oCdIGhlcmUgaXMgdGhlIENQRSBnYXRld2F5LCBub3QgdGhlIElTUC4gIFRoZSBDUEUgZ2F0 ZXdheSBtYXkgaGF2ZSBtdWx0aXBsZSB1cHN0cmVhbSBjb25uZWN0aW9ucy4gIEl0IGNhbuKAmXQg bmVjZXNzYXJpbHkgYXNzdW1lIHRoYXQgcHJvbWlzZXMgbWFkZSBieSB0aGUgdXBzdHJlYW0gd2ls bCBiZSBrZXB0LiAgQW5kIHNvIGFudGljaXBhdGluZyB0aGUgcG9zc2liaWxpdHkgb2YgYSByZW51 bWJlcmluZyBldmVudCBhbmQga2VlcGluZyB0aW1lcnMgc2hvcnQgZW5vdWdoIHRoYXQgdGhleSBj YW4gYmUgZXhwaXJlZCByZWFzb25hYmx5IHF1aWNrbHkgaW4gdGhlIGV2ZW50IG9mIGFuIGFjdHVh bCByZW51bWJlcmluZyBldmVudCwgd2hpbGUga2VlcGluZyB0aGVtIGxvbmcgZW5vdWdoIHRoYXQg dGhleSBkb27igJl0IGZsYXAsIHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIHRoaW5nIGZvciBhIENQ RSB0byBkby4NCg0KSGF2aW5nIHRoZSBob3N0IGtlZXAgYSBwcmVmaXggYXJvdW5kIGZvciBhIG1v bnRoIGluIHRoZSBhYnNlbmNlIG9mIGEgc2luZ2xlIFJBIGR1cmluZyB0aGF0IG1vbnRoIHNlZW1z IGxpa2Ugbm9uc2Vuc2ljYWwgYmVoYXZpb3IuICBJZiB0aGUgcHJlZml4IGlzIHRvIGJlIHZhbGlk IGZvciBhIG1vbnRoLCBwcmVzdW1hYmx5IGNvbW11bmljYXRpb24gd2lsbCBiZSBvY2N1cnJpbmcg ZnJlcXVlbnRseSBkdXJpbmcgdGhhdCBtb250aDsgaWYgaXQgaXMgbm90LCB0aGVuIGluIHdoYXQg c2Vuc2UgaXMgdGhlIHByZWZpeCB2YWxpZD8NCg0KV2hhdCBpcyB0aGUgbW90aXZhdGlvbiBmb3Ig c3VjaCBsb25nIGxpZmV0aW1lcz8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Wed Apr 8 10:57:17 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A63B3A14FE for ; Wed, 8 Apr 2020 10:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 h19TdItazKTM for ; Wed, 8 Apr 2020 10:57:11 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853E33A1504 for ; Wed, 8 Apr 2020 10:57:11 -0700 (PDT) Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 4D2AB4E11BA9; Wed, 8 Apr 2020 17:57:10 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 81D55318853E; Wed, 8 Apr 2020 19:57:04 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Wed, 8 Apr 2020 19:57:04 +0200 Cc: Ted Lemon , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters Content-Transfer-Encoding: quoted-printable Message-Id: References: <9593bb1a-001a-0ec8-712b-9dff80373838@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 17:57:16 -0000 >>>>>>> We have timers. We are just not using them appropriately. What's = the point of having PL and VL lifetimes in a way that they will never go = off in any meaningful timeframe? >>>>>> No. You are proposing to use the prefix timers for something they = were never designed for. >>>>>=20 >>>>> 1) I'm proposing to use prefix timers... for timing out timers :-) >>>>>=20 >>>>> The Preferred Lifetime, to deprecate an otherwise preferred = prefix. >>>>> The Valid Lifetime, to invalidate the prefix. >>>>>=20 >>>>> Just of curiousity, may I ask what do you think they are meant = for? (of course, wasting them by using huge values not being a valid = option). >>>> They are meant to support renumbering. >>>=20 >>> Part of renumbering is phasing out prefixes. And this is what we are = doing here. >> No you are not. >=20 > Let's agree to disagree. >=20 > I put a timer for addresses. Unless there's any sort of signal that = the configuration is current in a veeery reasonable period of time, I = phase out the prefix. I think you are mixing what you are proposing in 6man with what you are = proposing in v6ops. The current draft in v6ops is reasonable, if the review comments I = posted are included. The added text on lifetimes in this document is not. >> If you were doing renumbering, then you'd get two prefixes in DHCP = PD. One old expired (lifetimes 0), one new with lifetimes > 0. >=20 > This was already discussed on this mailing list. Please read = draft-ietf-v6ops-slaac-renum. Many operators have already spoke up on = the topic. I don't have much to add in addition to what has already been = said. >=20 >=20 >=20 >> If that simple operational rule was followed, then none of these = tweaks are required. (At least for this purpose). >=20 > If folks had follow the simple operational plan that everyone enables = v6, and then when everyone could simply disable IPv4, we would have = deployed v6 20 years ago, and we wouldn't have the ..load of = transition/co-existence mechanisms that we have. >=20 > But hey, engineering is a bit about solving problems in the real = world, rather than complaining that the problems are not solvable = because the planet should actually be spinning in the opposite = direction. I take it being condecending is your way of saying you have run out of = arguments? The point is that there are many ways of misconfiguring or doing the = mechanics of prefix delegation wrong. That doesn't mean we should adapt the standards to accommodate who do = not do it the way it is specified. Especially when those operational practices have bad implications on = end-users, and the mitigations proposed are potentially risky for the = majority who will never see a network "operated" this way. >>> A core design principle of the Internet is that as long as there is = a working path from source to destination, communications survive = possible outages. >> Oh, I'm not saying that we shouldn't make host behaviour more robust. = Rather the contrary. I'm just saying I don't think the proposed changes = are the right ones. >> Let me see if I find some spare time to write down how I would like = it to work. Don't hold your breath. >=20 > We have been discussing this problem for over one year now. Yes, you have. >=20 >=20 >>>> is not a tradeoff I'm willingto make. >>>> What's described in slaac-renum isn't a protocol problem. >>>=20 >>> I respect that you may have a different opinion and disagree. >>>=20 >>> Now, splitting your role as a participant, and your role as wg char, = may we have a wg call on draft-gont-6man-slaac-renum at 6man? >> If you want me to put my chair hat on, then you need to take that to = the 6man list. >=20 > I did, indeed: = https://mailarchive.ietf.org/arch/msg/ipv6/qO_vGJrDVMOC1fnOGa8DquONOAs/ = (at least for the second time). Cheers, Ole= From nobody Wed Apr 8 11:02:30 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413D83A09F7 for ; Wed, 8 Apr 2020 11:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dlfO7epPf80 for ; Wed, 8 Apr 2020 11:02:27 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD293A09F1 for ; Wed, 8 Apr 2020 11:02:27 -0700 (PDT) Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 3BEE54E11D6B; Wed, 8 Apr 2020 18:02:27 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 2F78B31888E7; Wed, 8 Apr 2020 20:02:21 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Wed, 8 Apr 2020 20:02:21 +0200 Cc: Bernie Volz , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 18:02:29 -0000 > Going back to your orignal comment: if you don't do garbage collection = (i.e. reasonable Valid Lifetime) on your prefixes/addresses, then that = means you wouldn't be able to communicate with the new "owner"/user of = the prefix -- because you consider that prefix to be local/on-link. > I'm not saying that I think there's a lot of chances that you might = need/want to communicate with the new user of the prefix. But if for = some reason (plain bad luck? :-) ) you needed, then you couldn't. >=20 > (that's why you don't want one-month valid lifetimes for PIOs) No, that's why the delegator needs to remove those prefixes properly. = I.e. by including them in DHCP with lifetime of 0. In the flash renumbering case, the delegator will set the lifetime to 0 = from whatever it was before. No need to "wait out" the lifetime. Long valid lifetimes affect what you put in DNS as TTL for the record = for example. Cheers, Ole= From nobody Wed Apr 8 11:27:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CAD3A1578 for ; Wed, 8 Apr 2020 11:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zw0Sa3JX5y0 for ; Wed, 8 Apr 2020 11:27:47 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D163A1573 for ; Wed, 8 Apr 2020 11:27:46 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id 14so698506qtp.1 for ; Wed, 08 Apr 2020 11:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=O9WZV9MjObPE25B1hmGOn76+nsdYwBxOfE3oQVtPa0Y=; b=Ko5tnbSJtzz0b8Llit8DI2BaH2W7ODtGyItYVYCXxg/t8wyZYIQMwzifYEu+VjYpY/ pqkMlu018FZ/OZlpR/b5to+mHPJFCBWZpktMeozW6rBqqNg7zYMYDWfSd27N5Wd887NM El+CdbSW5Rpj3QA4gb5G1xYhXa6jc2YFqbm3REYzcs0byiWGz2ieKLC2b+AYXd1Stzm6 Pz5Bc6tv8Ws2pli/+bN912ZlYiPmaNpVv/9BCJJO1jUB7ykVY2Ht3xY7qbG3bF8EDj9y MSLc9XQV6y61rukuDr0ilDRGQLcOEPX3IzkWoki2OOI3wpRUdwVAxvNvaOKSqrTPOO1k t0Gw== 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=O9WZV9MjObPE25B1hmGOn76+nsdYwBxOfE3oQVtPa0Y=; b=Dbjtfx/wNsq9pq4t1oBQpCW6+8rM366exzbDGAWTgMTs6V8SotkI3rk0hsgo5lG/hj uQnCI+13+5xc32KQ4wJbyUlMV+GPB+BynvxtTn13BKlTHo0Yf/7WmUY7RJWcczLGj/zy 7IflsOR1A8UiRqQ0nKSUCCVmC7OyzHxxhFADI5Xi6VhgVLIAfuefXIDnajZEDf94aw7X 452MeGZfLKDc0+Ym1USQUbitvoD7gEP0YGG6vhqfygCQ3ON0PdwSwTAyNDzkt3MLuOCC LeLTA2bIQBzyCF7eanO5J4+ev8fKGyHu/wUu4LUsuqnRYJYfudffAejcBJz9O34zJqDy VFAA== X-Gm-Message-State: AGi0PuawcO+KXCrJHbytgbU0DB1ugJE7zNPfXWuDTAMaKa+tIr6ym6Yh gEWvdSHPuDddejO7dkrx3nS+y/dhmWg= X-Google-Smtp-Source: APiQypIkmzPNa+zwS9nRbkBVWpfB2bba5kqYrx9dwnytmR9aqXVE75agaCv2lBOVodMdao2bx8EkQg== X-Received: by 2002:ac8:2224:: with SMTP id o33mr8564039qto.263.1586370465656; Wed, 08 Apr 2020 11:27:45 -0700 (PDT) Received: from [192.168.1.241] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id o205sm11867858qke.41.2020.04.08.11.27.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2020 11:27:44 -0700 (PDT) From: Ted Lemon Message-Id: <5AACFB5F-D67D-4779-B5EB-E6D8A58516F7@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C51AD48B-B9AB-4B18-A7E4-3628D8C828CA" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.6\)) Date: Wed, 8 Apr 2020 14:27:42 -0400 In-Reply-To: Cc: Fernando Gont , IPv6 Operations To: otroan@employees.org References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> X-Mailer: Apple Mail (2.3622.0.6) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 18:27:49 -0000 --Apple-Mail=_C51AD48B-B9AB-4B18-A7E4-3628D8C828CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 8, 2020, at 2:02 PM, otroan@employees.org wrote: > No, that's why the delegator needs to remove those prefixes properly. = I.e. by including them in DHCP with lifetime of 0. > In the flash renumbering case, the delegator will set the lifetime to = 0 from whatever it was before. No need to "wait out" the lifetime. >=20 > Long valid lifetimes affect what you put in DNS as TTL for the record = for example. Okay, but you are talking about a very different operational use case. = This is how you would do things in a data center. In the case of a CPE router, it=E2=80=99s not safe to assume the router = won=E2=80=99t be unplugged or power cycled. You probably don=E2=80=99t = _want_ to use long TTLs on domain names, if any are published=E2=80=94e.g.= , for mDNS we use a TTL of 75 minutes, and do a refresh at 60 minutes; = we do the same thing for Service Registration Protocol (DNS updates for = DNSSD), although that=E2=80=99s not widely deployed at present. So in this case, where your device may be power cycled and lose its = state, or where the end user may simply unplug one device and plug in = another, having a really long preferred lifetime makes zero sense. = Obviously, having a shorter lifetime does not solve the problem of = cleaning up stale prefixes fast enough to prevent routing problems, but = we still want those stale prefixes to be cleaned up. As you say, there = are two different issues here. Reasonably short address lifetimes = avoids keeping addresses around for a month when they are stale and = aren=E2=80=99t going to be explicitly deprecated. For source address = selection and route selection, this doesn=E2=80=99t help, but it=E2=80=99s= still worth doing. --Apple-Mail=_C51AD48B-B9AB-4B18-A7E4-3628D8C828CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Apr 8, 2020, at 2:02 PM, otroan@employees.org wrote:
No, that's why the delegator needs to remove those prefixes = properly. I.e. by including them in DHCP with lifetime of 0.
In the flash = renumbering case, the delegator will set the lifetime to 0 from whatever = it was before. No need to "wait out" the lifetime.

Long valid = lifetimes affect what you put in DNS as TTL for the record for = example.

Okay, but you are talking about a very different operational = use case.  This is how you would do things in a data = center.

In the = case of a CPE router, it=E2=80=99s not safe to assume the router won=E2=80= =99t be unplugged or power cycled.  You probably don=E2=80=99t = _want_ to use long TTLs on domain names, if any are published=E2=80=94e.g.= , for mDNS we use a TTL of 75 minutes, and do a refresh at 60 minutes; = we do the same thing for Service Registration Protocol (DNS updates for = DNSSD), although that=E2=80=99s not widely deployed at = present.

So in = this case, where your device may be power cycled and lose its state, or = where the end user may simply unplug one device and plug in another, = having a really long preferred lifetime makes zero sense. =  Obviously, having a shorter lifetime does not solve the problem of = cleaning up stale prefixes fast enough to prevent routing problems, but = we still want those stale prefixes to be cleaned up.  As you say, = there are two different issues here.  Reasonably short address = lifetimes avoids keeping addresses around for a month when they are = stale and aren=E2=80=99t going to be explicitly deprecated.  For = source address selection and route selection, this doesn=E2=80=99t help, = but it=E2=80=99s still worth doing.

= --Apple-Mail=_C51AD48B-B9AB-4B18-A7E4-3628D8C828CA-- From nobody Wed Apr 8 11:29:17 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8D13A1590; Wed, 8 Apr 2020 11:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 bhHHX98q7Yq6; Wed, 8 Apr 2020 11:29:13 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554D33A158C; Wed, 8 Apr 2020 11:29:12 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 B16D980900; Wed, 8 Apr 2020 20:29:08 +0200 (CEST) To: otroan@employees.org Cc: Ted Lemon , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters , "6man@ietf.org" <6man@ietf.org> References: <9593bb1a-001a-0ec8-712b-9dff80373838@si6networks.com> From: Fernando Gont Message-ID: Date: Wed, 8 Apr 2020 15:28:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] 6man's draft-ietf-slaac-renum (Re: WG Last Call on draft-ietf-v6ops-cpe-slaac-renum) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 18:29:16 -0000 On 8/4/20 14:57, otroan@employees.org wrote: >>>>>>>> We have timers. We are just not using them appropriately. What's the point of having PL and VL lifetimes in a way that they will never go off in any meaningful timeframe? >>>>>>> No. You are proposing to use the prefix timers for something they were never designed for. >>>>>> >>>>>> 1) I'm proposing to use prefix timers... for timing out timers :-) >>>>>> >>>>>> The Preferred Lifetime, to deprecate an otherwise preferred prefix. >>>>>> The Valid Lifetime, to invalidate the prefix. >>>>>> >>>>>> Just of curiousity, may I ask what do you think they are meant for? (of course, wasting them by using huge values not being a valid option). >>>>> They are meant to support renumbering. >>>> >>>> Part of renumbering is phasing out prefixes. And this is what we are doing here. >>> No you are not. >> >> Let's agree to disagree. >> >> I put a timer for addresses. Unless there's any sort of signal that the configuration is current in a veeery reasonable period of time, I phase out the prefix. > > I think you are mixing what you are proposing in 6man with what you are proposing in v6ops. > The current draft in v6ops is reasonable, if the review comments I posted are included. Not sure what the "review comments you posted" are. I had responded with proposed text to address your comments. Are you referring to that? If so, yes of course that will be incorporated. > The added text on lifetimes in this document is not. The text on lifetimes was suggested in the WGLC thread. Please, even if you disagree, respond on that thread, because this one has deviated from the v6ops document for a while now. Of course I have my own view on the topic. BUt I don't mind the outcome -- the point is to have that discussed in the separate thread, so that we can agree on *something*. Also, whatever you object about the proposed text, please mark it clearly. Now, going back to the 6man document, it essentially has two parts: 1) Using appropriate lifetimes 2) Inferring stale information. #1 is similar to the new proposed text for the document you seem to object. -- And I don't see what, specifically, you object about it. #2 Not sure what you don't like about it. [...] >>> If that simple operational rule was followed, then none of these tweaks are required. (At least for this purpose). >> >> If folks had follow the simple operational plan that everyone enables v6, and then when everyone could simply disable IPv4, we would have deployed v6 20 years ago, and we wouldn't have the ..load of transition/co-existence mechanisms that we have. >> >> But hey, engineering is a bit about solving problems in the real world, rather than complaining that the problems are not solvable because the planet should actually be spinning in the opposite direction. > > I take it being condecending is your way of saying you have run out of arguments? Clearly not. I wasn't being condescending. I was actually saying that quite often one need to solve scenarios that, on paper, don't take place. But in practice, they do. So you tell me that you have a paper that says how to do renumbering -- that's great, and I like it. But at the same time, we have people telling us, that they have real world scenarios that our current protocols, as is, don't handle properly. And in many cases (such as a user who's ISP does dynamic prefixes, or who has a CPE that announces PIO lifetimes past the PD lease), they have no control over the elements that trigger such scenarios. * In the best interest of v6ops, and in the best interest of 6man, we probably want, to the extent that is possible, that our protocols handle such scenarios gracefully. -- in a way, you could even frame this in Postel's principle. (handle in a gracefully manner scenarios that you thing shouldn't happen). * We do a bad service to the ISP that want to deploy IPv6 and face these problems while deploying (this work was indeed triggered by an ISP deploying IPv6) -- it's a hassle they have to deal with, and it's calls they are going to get. And also, because if they are "lucky", the traffic they expected to go over IPv6, will go over IPv4 -- exactly the opposite of what they were expecting. * And we do a bad service to the user, because if as soon as the ISP turns on IPv6, his/her connections gets stalled frequently, and the users somehow realizes that that happened since the ISP enabled IPv6 that's another one that goes into the basket of -> disable IPv6. > The point is that there are many ways of misconfiguring or doing the mechanics of prefix delegation wrong. > That doesn't mean we should adapt the standards to accommodate who do not do it the way it is specified. I don't see the point of repeating what a number of operators mentioned on this list already: there are multiple scenarios for which flash-renumbering may happen. > Especially when those operational practices have bad implications on end-users, and the mitigations proposed are potentially risky for the majority who will never see a network "operated" this way. You claim "this is potentially risky". Could you please elaborate what, specifically, you think is risky? And what's the scenario where what's being proposed would fail? >>>> A core design principle of the Internet is that as long as there is a working path from source to destination, communications survive possible outages. >>> Oh, I'm not saying that we shouldn't make host behaviour more robust. Rather the contrary. I'm just saying I don't think the proposed changes are the right ones. >>> Let me see if I find some spare time to write down how I would like it to work. Don't hold your breath. >> >> We have been discussing this problem for over one year now. > > Yes, you have. No, not "me". We as a group. I understand that you probably have your own view on the topic. But I do believe that, ultimately, it is the *wg's* decision what to do with documents. So... why can't the wg be polled about it? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Apr 8 11:38:06 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3D83A155C for ; Wed, 8 Apr 2020 11:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ic0pBPUPSVzj for ; Wed, 8 Apr 2020 11:38:03 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D503A154D for ; Wed, 8 Apr 2020 11:38:02 -0700 (PDT) Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id CE5614E11B0D; Wed, 8 Apr 2020 18:38:01 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 0118E318A46E; Wed, 8 Apr 2020 20:37:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: <5AACFB5F-D67D-4779-B5EB-E6D8A58516F7@fugue.com> Date: Wed, 8 Apr 2020 20:37:55 +0200 Cc: Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> <5AACFB5F-D67D-4779-B5EB-E6D8A58516F7@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 18:38:04 -0000 Ted, >> No, that's why the delegator needs to remove those prefixes properly. = I.e. by including them in DHCP with lifetime of 0. >> In the flash renumbering case, the delegator will set the lifetime to = 0 from whatever it was before. No need to "wait out" the lifetime. >>=20 >> Long valid lifetimes affect what you put in DNS as TTL for the record = for example. >=20 > Okay, but you are talking about a very different operational use case. = This is how you would do things in a data center. >=20 > In the case of a CPE router, it=E2=80=99s not safe to assume the = router won=E2=80=99t be unplugged or power cycled. You probably don=E2=80= =99t _want_ to use long TTLs on domain names, if any are = published=E2=80=94e.g., for mDNS we use a TTL of 75 minutes, and do a = refresh at 60 minutes; we do the same thing for Service Registration = Protocol (DNS updates for DNSSD), although that=E2=80=99s not widely = deployed at present. >=20 > So in this case, where your device may be power cycled and lose its = state, or where the end user may simply unplug one device and plug in = another, having a really long preferred lifetime makes zero sense. = Obviously, having a shorter lifetime does not solve the problem of = cleaning up stale prefixes fast enough to prevent routing problems, but = we still want those stale prefixes to be cleaned up. As you say, there = are two different issues here. Reasonably short address lifetimes = avoids keeping addresses around for a month when they are stale and = aren=E2=80=99t going to be explicitly deprecated. For source address = selection and route selection, this doesn=E2=80=99t help, but it=E2=80=99s= still worth doing. >=20 You seem to be implying something here. Why does it matter if a CPE is unplugged or power cycled? (Well, apart = from the obvious of being unable to forward packets for the duration). Ole= From nobody Wed Apr 8 11:43:37 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F323A156C for ; Wed, 8 Apr 2020 11:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8O2NXb8oeNi for ; Wed, 8 Apr 2020 11:43:33 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817733A156B for ; Wed, 8 Apr 2020 11:43:33 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id z15so1319394qki.7 for ; Wed, 08 Apr 2020 11:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OJ3lqK94LDmZRNu2cr47Ey4jTdre6FXLkSfxWyzZGok=; b=WZ7zD0fH+dhGjPsxcgG8WdZV/nIqH122giCpybQc0wEq+ghkAvO5oVDypE1DZmIVIf XgwPo8N77AdegiTGM6NY/KS7UHJYXTE4KngCQDiYlBvMvq1qXMRLUXRJGUhItnbQ2/Y1 nsNPTdnC+9w38IcunJ7jpVBJzu1v549Sigo1tiOMJKcQ5cFTR4C1u4PcrGBwS+QRS+5M zuXsgw+kek9O88NLfHaYZP476gmsW7UD/0fn19Ld307HrXBFvINmCxM2vVu2fq/l/aT0 HuJEGQ5WHc3S5nZlN+wJ2Gs+dMdFDGrOL3qI4Mr9febC4l4v/uS/0PJU6/djXtQzqSsa Bn4A== 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=OJ3lqK94LDmZRNu2cr47Ey4jTdre6FXLkSfxWyzZGok=; b=Hk3o87nZrI3RtNQawb6C0fvQgpZVIDIR0bk6/t2raE8AzrGu8zLIZLGTxBQAteL6G3 E0lMZ7iHoKfZcjSI7/k1GdTwvPxkMxDMB/ztpJ6kso79JWWZSr1eQLunRCTe1qAJ3dzZ V/iFpYa1oNzxoJfWmHWT2ec1ktBWxc54PNQmLpptALnNyuEOw8476k3cQuyG4Ieasd8j WzNU67VCT/wMxXZ4OqIOeFV9saMWdcdQN8ejz+QpGtkNtdePe938Vq9792rA4GtsixpR NHBnl93yAK1SsshHOV46ozhqgw3D0Q5D7hmYFUY4u8+G1RCRosUyQRlxFNgIb8dWMTBf RORg== X-Gm-Message-State: AGi0PuaoGCDbmIU+Plsb0qBxHz2094a3hadQYsNql+mixt1iYyLLd28k /iNZ3hsB/tCI54TYgVevFXF+nmbGRKw= X-Google-Smtp-Source: APiQypInQTop9TFbXpUYfAbNkATlRUmH+bZVoepc1M0ecyUo0FU+qzSxDUSUw+XW6hTdyv0zOKGciA== X-Received: by 2002:a37:79c6:: with SMTP id u189mr8863072qkc.96.1586371412512; Wed, 08 Apr 2020 11:43:32 -0700 (PDT) Received: from [192.168.1.241] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id r9sm3096169qke.5.2020.04.08.11.43.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2020 11:43:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.6\)) From: Ted Lemon In-Reply-To: Date: Wed, 8 Apr 2020 14:43:29 -0400 Cc: Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> <5AACFB5F-D67D-4779-B5EB-E6D8A58516F7@fugue.com> To: Ole Troan X-Mailer: Apple Mail (2.3622.0.6) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 18:43:35 -0000 On Apr 8, 2020, at 2:37 PM, otroan@employees.org wrote: >>> No, that's why the delegator needs to remove those prefixes = properly. I.e. by including them in DHCP with lifetime of 0. >>> In the flash renumbering case, the delegator will set the lifetime = to 0 from whatever it was before. No need to "wait out" the lifetime. >>>=20 >>> Long valid lifetimes affect what you put in DNS as TTL for the = record for example. >>=20 >> Okay, but you are talking about a very different operational use = case. This is how you would do things in a data center. >>=20 >> In the case of a CPE router, it=E2=80=99s not safe to assume the = router won=E2=80=99t be unplugged or power cycled. You probably don=E2=80= =99t _want_ to use long TTLs on domain names, if any are = published=E2=80=94e.g., for mDNS we use a TTL of 75 minutes, and do a = refresh at 60 minutes; we do the same thing for Service Registration = Protocol (DNS updates for DNSSD), although that=E2=80=99s not widely = deployed at present. >>=20 >> So in this case, where your device may be power cycled and lose its = state, or where the end user may simply unplug one device and plug in = another, having a really long preferred lifetime makes zero sense. = Obviously, having a shorter lifetime does not solve the problem of = cleaning up stale prefixes fast enough to prevent routing problems, but = we still want those stale prefixes to be cleaned up. As you say, there = are two different issues here. Reasonably short address lifetimes = avoids keeping addresses around for a month when they are stale and = aren=E2=80=99t going to be explicitly deprecated. For source address = selection and route selection, this doesn=E2=80=99t help, but it=E2=80=99s= still worth doing. >>=20 >=20 > You seem to be implying something here. > Why does it matter if a CPE is unplugged or power cycled? (Well, apart = from the obvious of being unable to forward packets for the duration). It matters if the CPE doesn=E2=80=99t maintain state between power = cycles, and gets a different prefix when it comes back. And it matters = if the CPE is swapped out without a clean shutdown that would result in = the prefix being deprecated, and subsequently gets a different prefix = from the ISP. In both of these cases, we want the old prefix to go = away sooner than a month. This doesn=E2=80=99t absolve us of having to = do the work to make sure that things work while that prefix is still = present, but we should also be letting it die cleanly. I suppose the counterargument would be that if it=E2=80=99s still valid, = we still want to use it for existing connections, but it seems unlikely = that this could work in either of the situations I=E2=80=99m describing. From nobody Wed Apr 8 11:56:23 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E073A1610 for ; Wed, 8 Apr 2020 11:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svb0Jc4CEgqR for ; Wed, 8 Apr 2020 11:56:08 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B6D3A1623 for ; Wed, 8 Apr 2020 11:56:07 -0700 (PDT) Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 9F9864E11B0A; Wed, 8 Apr 2020 18:56:06 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 627AF318B6B4; Wed, 8 Apr 2020 20:56:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Wed, 8 Apr 2020 20:56:00 +0200 Cc: Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> <5AACFB5F-D67D-4779-B5EB-E6D8A58516F7@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 18:56:16 -0000 >>>> No, that's why the delegator needs to remove those prefixes = properly. I.e. by including them in DHCP with lifetime of 0. >>>> In the flash renumbering case, the delegator will set the lifetime = to 0 from whatever it was before. No need to "wait out" the lifetime. >>>>=20 >>>> Long valid lifetimes affect what you put in DNS as TTL for the = record for example. >>>=20 >>> Okay, but you are talking about a very different operational use = case. This is how you would do things in a data center. >>>=20 >>> In the case of a CPE router, it=E2=80=99s not safe to assume the = router won=E2=80=99t be unplugged or power cycled. You probably don=E2=80= =99t _want_ to use long TTLs on domain names, if any are = published=E2=80=94e.g., for mDNS we use a TTL of 75 minutes, and do a = refresh at 60 minutes; we do the same thing for Service Registration = Protocol (DNS updates for DNSSD), although that=E2=80=99s not widely = deployed at present. >>>=20 >>> So in this case, where your device may be power cycled and lose its = state, or where the end user may simply unplug one device and plug in = another, having a really long preferred lifetime makes zero sense. = Obviously, having a shorter lifetime does not solve the problem of = cleaning up stale prefixes fast enough to prevent routing problems, but = we still want those stale prefixes to be cleaned up. As you say, there = are two different issues here. Reasonably short address lifetimes = avoids keeping addresses around for a month when they are stale and = aren=E2=80=99t going to be explicitly deprecated. For source address = selection and route selection, this doesn=E2=80=99t help, but it=E2=80=99s= still worth doing. >>>=20 >>=20 >> You seem to be implying something here. >> Why does it matter if a CPE is unplugged or power cycled? (Well, = apart from the obvious of being unable to forward packets for the = duration). >=20 > It matters if the CPE doesn=E2=80=99t maintain state between power = cycles, and gets a different prefix when it comes back. And it matters = if the CPE is swapped out without a clean shutdown that would result in = the prefix being deprecated, and subsequently gets a different prefix = from the ISP. In both of these cases, we want the old prefix to go = away sooner than a month. This doesn=E2=80=99t absolve us of having to = do the work to make sure that things work while that prefix is still = present, but we should also be letting it die cleanly. >=20 > I suppose the counterargument would be that if it=E2=80=99s still = valid, we still want to use it for existing connections, but it seems = unlikely that this could work in either of the situations I=E2=80=99m = describing. Right, so the broken operational practice of flash renumbering without = deprecating the old prefix approach to PD. Let's make clear that's neither the recommended nor the typical way ISPs = operate their networks. In a typicaly deployment swapping CPEs or power cycling them does of = course not affect the delegated prefix. Ole From nobody Wed Apr 8 12:03:54 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3C93A15B6 for ; Wed, 8 Apr 2020 12:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3Shue0xJyO2 for ; Wed, 8 Apr 2020 12:03:50 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D653A15B4 for ; Wed, 8 Apr 2020 12:03:50 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id 71so755566qtc.12 for ; Wed, 08 Apr 2020 12:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=rEGuJGspHzhclpZzLItOJC2M0DRaljs1JOso8+QM5PQ=; b=k7GApUm9qsX9HPtflZ987X8F4AGZoj/fxWO0+KYXHnNNR+40LTRNiFxXCNrM9iza6v WY91uGXUY9iAkatF61szdWeTxbD3SaEjsCvDG4BHkzsDG96F8rgao/A2oVudH4Wl9Z+s C8i9J4ow+zuErJpGhAJkvViKg3Cbyzu4DEB1gynMj9PGm0R7Y/F6R06oHtzSEiuQcraA yBHMb7FSHrSf1ZhJQWzhzlNVlLCuQBijT+PrjzlyEQzzIN4O475BTalUWJjUQs4VAY+k qpbhLGRTRNyVZ87xn/qeeKhLPJ/h8CoZFixCt/ZQnuz6vFY50QEBP/jME9d0y9wGJqlt LjHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=rEGuJGspHzhclpZzLItOJC2M0DRaljs1JOso8+QM5PQ=; b=rs/m0C25tAgpziIWAgsU7G3fdkh7YuaPUDV9JL/qAO+cmfzrw4PTEz46K8Osd7kDOD 33iBETnHzc9NsEWnk/aOXYII/cpjqvu75FnAYx0dcCfqhCPwTMAatHxl81+gvW3sNdWG CrlAzqUc+GJyxuZ4DjuIFxfRPizKsks6JJG+zD52LFgnysy62XmOzXj1EqPsU5L9J9nf IdKDiVVLWX8jI/MHxJTyxsj0YpJ4sWVHEy/J+Nsx8E9gnJuL5k96HXAoo4K5Xlkq45eH xVuJ5unMh9fwQEWNWQT/nLPWkE/PMdwJ0TtE9tQS/OyybhOOhuKBnzAMW/khmp7LHXHb oX/w== X-Gm-Message-State: AGi0PubcgsI794d7mJNk8vRjSxTuMeAVJrQCKJlF5NHwxRtAT95RY4Sa rg7JQLJhAamJVKme24TsNzdf9qhq99Y= X-Google-Smtp-Source: APiQypJmZzloTXpTSFFYF3US1/0HVUJAw80ly/PaQXJZgT/ZdkeFUPoIPkb9Ji6M8M1S924YKAQJTA== X-Received: by 2002:ac8:1b9d:: with SMTP id z29mr7809603qtj.212.1586372629340; Wed, 08 Apr 2020 12:03:49 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:201b:83ea:1756:69e4? ([2601:18b:300:36ee:201b:83ea:1756:69e4]) by smtp.gmail.com with ESMTPSA id o5sm10259825qkh.77.2020.04.08.12.03.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Apr 2020 12:03:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 8 Apr 2020 15:03:47 -0400 Message-Id: <4E01DB76-DBF4-4B6D-B054-2A011E0AC3A6@fugue.com> References: Cc: Fernando Gont , IPv6 Operations In-Reply-To: To: otroan@employees.org X-Mailer: iPad Mail (17E255) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 19:03:52 -0000 On Apr 8, 2020, at 2:56 PM, otroan@employees.org wrote: >>>> power cycled. You probably don=E2=80=99t _want_ to use long TTLs on do= main names, if any are published=E2=80=94e.g., for mDNS we use a TTL of 75 m= inutes, and do a refresh at 60 minutes; we do the same thing for Service Reg= istration Protocol (DNS updates for DNSSD), although that=E2=80=99s not wide= ly deployed at present. >>>>=20 >>>> So in this case, where your device may be power cycled and lose its sta= te, or where the end user may simply unplug one device and plug in another, h= aving a really long preferred lifetime makes zero sense. Obviously, having a= shorter lifetime does not solve the problem of cleaning up stale prefixes f= ast enough to prevent routing problems, but we still want those stale prefix= es to be cleaned up. As you say, there are two different issues here. Reas= onably short address lifetimes avoids keeping addresses around for a month w= hen they are stale and aren=E2=80=99t going to be explicitly deprecated. Fo= r source address selection and route selection, this doesn=E2=80=99t help, b= ut it=E2=80=99s still worth doing. >>>>=20 >>>=20 >>> You seem to be implying something here. >>> Why does it matter if a CPE is unplugged or power cycled? (Well, apart f= rom the obvious of being unable to forward packets for the duration). >>=20 >> It matters if the CPE doesn=E2=80=99t maintain state between power cycles= , and gets a different prefix when it comes back. And it matters if the CPE i= s swapped out without a clean shutdown that would result in the prefix being= deprecated, and subsequently gets a different prefix from the ISP. In bot= h of these cases, we want the old prefix to go away sooner than a month. Th= is doesn=E2=80=99t absolve us of having to do the work to make sure that thi= ngs work while that prefix is still present, but we should also be letting i= t die cleanly. >>=20 >> I suppose the counterargument would be that if it=E2=80=99s still valid, w= e still want to use it for existing connections, but it seems unlikely that t= his could work in either of the situations I=E2=80=99m describing. >=20 > Right, so the broken operational practice of flash renumbering without dep= recating the old prefix approach to PD. > Let's make clear that's neither the recommended nor the typical way ISPs o= perate their networks. >=20 > In a typicaly deployment swapping CPEs or power cycling them does of cours= e not affect the delegated prefix. Is it true that this is flash renumbering? Where in the PD spec does it say= that the server has to give the same CP (customer premises) the same prefix= ? How does it identify the CP if the CPE has changed? I know that there ar= e ways to do that, but there is no RFC I know of that says how to do that, o= r that requires that this be done. Does the PD spec say that the ISP has to give the CPE the same prefix, assum= ing that it _can_ identify it? As I said earlier, I think it=E2=80=99s the case that if a PD is issued, the= DHCP server has to honor it until it=E2=80=99s no longer valid, but unless w= e require that it return the same prefix in this case when the CPE device do= esn=E2=80=99t explicitly ask for it, there is a significant gap here. From nobody Wed Apr 8 12:17:18 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25C23A0BEA for ; Wed, 8 Apr 2020 12:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx172zhIxSz6 for ; Wed, 8 Apr 2020 12:17:14 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7E93A0BE7 for ; Wed, 8 Apr 2020 12:17:14 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 0747B831C9; Wed, 8 Apr 2020 21:17:10 +0200 (CEST) To: otroan@employees.org, Ted Lemon Cc: IPv6 Operations References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> <5AACFB5F-D67D-4779-B5EB-E6D8A58516F7@fugue.com> From: Fernando Gont Message-ID: <28b956ea-2f7c-ffbf-4920-ea975df0f0f9@si6networks.com> Date: Wed, 8 Apr 2020 16:16:51 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 19:17:17 -0000 On 8/4/20 15:56, otroan@employees.org wrote: >>>>> No, that's why the delegator needs to remove those prefixes properly. I.e. by including them in DHCP with lifetime of 0. >>>>> In the flash renumbering case, the delegator will set the lifetime to 0 from whatever it was before. No need to "wait out" the lifetime. >>>>> >>>>> Long valid lifetimes affect what you put in DNS as TTL for the record for example. >>>> >>>> Okay, but you are talking about a very different operational use case. This is how you would do things in a data center. >>>> >>>> In the case of a CPE router, it’s not safe to assume the router won’t be unplugged or power cycled. You probably don’t _want_ to use long TTLs on domain names, if any are published—e.g., for mDNS we use a TTL of 75 minutes, and do a refresh at 60 minutes; we do the same thing for Service Registration Protocol (DNS updates for DNSSD), although that’s not widely deployed at present. >>>> >>>> So in this case, where your device may be power cycled and lose its state, or where the end user may simply unplug one device and plug in another, having a really long preferred lifetime makes zero sense. Obviously, having a shorter lifetime does not solve the problem of cleaning up stale prefixes fast enough to prevent routing problems, but we still want those stale prefixes to be cleaned up. As you say, there are two different issues here. Reasonably short address lifetimes avoids keeping addresses around for a month when they are stale and aren’t going to be explicitly deprecated. For source address selection and route selection, this doesn’t help, but it’s still worth doing. >>>> >>> >>> You seem to be implying something here. >>> Why does it matter if a CPE is unplugged or power cycled? (Well, apart from the obvious of being unable to forward packets for the duration). >> >> It matters if the CPE doesn’t maintain state between power cycles, and gets a different prefix when it comes back. And it matters if the CPE is swapped out without a clean shutdown that would result in the prefix being deprecated, and subsequently gets a different prefix from the ISP. In both of these cases, we want the old prefix to go away sooner than a month. This doesn’t absolve us of having to do the work to make sure that things work while that prefix is still present, but we should also be letting it die cleanly. >> >> I suppose the counterargument would be that if it’s still valid, we still want to use it for existing connections, but it seems unlikely that this could work in either of the situations I’m describing. > > Right, so the broken operational practice of flash renumbering without deprecating the old prefix approach to PD. > Let's make clear that's neither the recommended nor the typical way ISPs operate their network This seems to disagree with your claim: https://indico.uknof.org.uk/event/41/contributions/542/attachments/712/866/bcop-ipv6-prefix-v9.pdf 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 Apr 8 12:17:59 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E533A0BE5 for ; Wed, 8 Apr 2020 12:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOV8Ke4DvHan for ; Wed, 8 Apr 2020 12:17:55 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C64A3A169E for ; Wed, 8 Apr 2020 12:17:47 -0700 (PDT) Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 9A0024E11C89; Wed, 8 Apr 2020 19:17:46 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 8EC61318C64E; Wed, 8 Apr 2020 21:17:40 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: <4E01DB76-DBF4-4B6D-B054-2A011E0AC3A6@fugue.com> Date: Wed, 8 Apr 2020 21:17:40 +0200 Cc: Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E01DB76-DBF4-4B6D-B054-2A011E0AC3A6@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 19:17:58 -0000 >>>>> power cycled. You probably don=E2=80=99t _want_ to use long TTLs = on domain names, if any are published=E2=80=94e.g., for mDNS we use a = TTL of 75 minutes, and do a refresh at 60 minutes; we do the same thing = for Service Registration Protocol (DNS updates for DNSSD), although = that=E2=80=99s not widely deployed at present. >>>>>=20 >>>>> So in this case, where your device may be power cycled and lose = its state, or where the end user may simply unplug one device and plug = in another, having a really long preferred lifetime makes zero sense. = Obviously, having a shorter lifetime does not solve the problem of = cleaning up stale prefixes fast enough to prevent routing problems, but = we still want those stale prefixes to be cleaned up. As you say, there = are two different issues here. Reasonably short address lifetimes = avoids keeping addresses around for a month when they are stale and = aren=E2=80=99t going to be explicitly deprecated. For source address = selection and route selection, this doesn=E2=80=99t help, but it=E2=80=99s= still worth doing. >>>>>=20 >>>>=20 >>>> You seem to be implying something here. >>>> Why does it matter if a CPE is unplugged or power cycled? (Well, = apart from the obvious of being unable to forward packets for the = duration). >>>=20 >>> It matters if the CPE doesn=E2=80=99t maintain state between power = cycles, and gets a different prefix when it comes back. And it matters = if the CPE is swapped out without a clean shutdown that would result in = the prefix being deprecated, and subsequently gets a different prefix = from the ISP. In both of these cases, we want the old prefix to go = away sooner than a month. This doesn=E2=80=99t absolve us of having to = do the work to make sure that things work while that prefix is still = present, but we should also be letting it die cleanly. >>>=20 >>> I suppose the counterargument would be that if it=E2=80=99s still = valid, we still want to use it for existing connections, but it seems = unlikely that this could work in either of the situations I=E2=80=99m = describing. >>=20 >> Right, so the broken operational practice of flash renumbering = without deprecating the old prefix approach to PD. >> Let's make clear that's neither the recommended nor the typical way = ISPs operate their networks. >>=20 >> In a typicaly deployment swapping CPEs or power cycling them does of = course not affect the delegated prefix. >=20 > Is it true that this is flash renumbering? Where in the PD spec does = it say that the server has to give the same CP (customer premises) the = same prefix? How does it identify the CP if the CPE has changed? I = know that there are ways to do that, but there is no RFC I know of that = says how to do that, or that requires that this be done. >=20 > Does the PD spec say that the ISP has to give the CPE the same prefix, = assuming that it _can_ identify it? >=20 > As I said earlier, I think it=E2=80=99s the case that if a PD is = issued, the DHCP server has to honor it until it=E2=80=99s no longer = valid, but unless we require that it return the same prefix in this case = when the CPE device doesn=E2=80=99t explicitly ask for it, there is a = significant gap here. Sorry, I don't see the gap. All deployments I am aware of use the remote-id / option-82 equivalent = option to identify subscribers. Most operators are a lot more clueful about this than us here. Think of PD as a contract. The ISP promises to lease the prefix to the = subscriber for the time stated. The ISP can still do flash renumbering (although that's likely to induce = a customer call) in two ways. One, just ignore it's earlier promise and give the subscriber a new = prefix (which introduces all the problems Fernado wants to use prefix = lifetimes to solve), or it can include the old prefix with lifetimes 0 = (violating it's earlier promise, but at least being explicit) and = advertise a new prefix. Cheers, Ole= From nobody Wed Apr 8 12:20:54 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9773A1608 for ; Wed, 8 Apr 2020 12:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoSpklsTjXgT for ; Wed, 8 Apr 2020 12:20:50 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF983A15FD for ; Wed, 8 Apr 2020 12:20:50 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79d:53aa:d30:7cd9:be0:e3ee:7b15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id AD0494E11B0D; Wed, 8 Apr 2020 19:20:49 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 9282A318C978; Wed, 8 Apr 2020 21:20:43 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: <28b956ea-2f7c-ffbf-4920-ea975df0f0f9@si6networks.com> Date: Wed, 8 Apr 2020 21:20:43 +0200 Cc: Ted Lemon , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <6D3632A9-30CF-4D0A-A7FF-E2CDD6EAA2EB@employees.org> References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> <5AACFB5F-D67D-4779-B5EB-E6D8A58516F7@fugue.com> <28b956ea-2f7c-ffbf-4920-ea975df0f0f9@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 19:20:53 -0000 >>>>>> No, that's why the delegator needs to remove those prefixes = properly. I.e. by including them in DHCP with lifetime of 0. >>>>>> In the flash renumbering case, the delegator will set the = lifetime to 0 from whatever it was before. No need to "wait out" the = lifetime. >>>>>>=20 >>>>>> Long valid lifetimes affect what you put in DNS as TTL for the = record for example. >>>>>=20 >>>>> Okay, but you are talking about a very different operational use = case. This is how you would do things in a data center. >>>>>=20 >>>>> In the case of a CPE router, it=E2=80=99s not safe to assume the = router won=E2=80=99t be unplugged or power cycled. You probably don=E2=80= =99t _want_ to use long TTLs on domain names, if any are = published=E2=80=94e.g., for mDNS we use a TTL of 75 minutes, and do a = refresh at 60 minutes; we do the same thing for Service Registration = Protocol (DNS updates for DNSSD), although that=E2=80=99s not widely = deployed at present. >>>>>=20 >>>>> So in this case, where your device may be power cycled and lose = its state, or where the end user may simply unplug one device and plug = in another, having a really long preferred lifetime makes zero sense. = Obviously, having a shorter lifetime does not solve the problem of = cleaning up stale prefixes fast enough to prevent routing problems, but = we still want those stale prefixes to be cleaned up. As you say, there = are two different issues here. Reasonably short address lifetimes = avoids keeping addresses around for a month when they are stale and = aren=E2=80=99t going to be explicitly deprecated. For source address = selection and route selection, this doesn=E2=80=99t help, but it=E2=80=99s= still worth doing. >>>>>=20 >>>>=20 >>>> You seem to be implying something here. >>>> Why does it matter if a CPE is unplugged or power cycled? (Well, = apart from the obvious of being unable to forward packets for the = duration). >>>=20 >>> It matters if the CPE doesn=E2=80=99t maintain state between power = cycles, and gets a different prefix when it comes back. And it matters = if the CPE is swapped out without a clean shutdown that would result in = the prefix being deprecated, and subsequently gets a different prefix = from the ISP. In both of these cases, we want the old prefix to go = away sooner than a month. This doesn=E2=80=99t absolve us of having to = do the work to make sure that things work while that prefix is still = present, but we should also be letting it die cleanly. >>>=20 >>> I suppose the counterargument would be that if it=E2=80=99s still = valid, we still want to use it for existing connections, but it seems = unlikely that this could work in either of the situations I=E2=80=99m = describing. >> Right, so the broken operational practice of flash renumbering = without deprecating the old prefix approach to PD. >> Let's make clear that's neither the recommended nor the typical way = ISPs operate their network > This seems to disagree with your claim: = https://indico.uknof.org.uk/event/41/contributions/542/attachments/712/866= /bcop-ipv6-prefix-v9.pdf That presentation recommends persistent prefixes. My point exactly. Ole= From nobody Wed Apr 8 12:28:40 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E7C3A1628 for ; Wed, 8 Apr 2020 12:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=E5JuXkcn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qZeR95H2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozJeSlu3LNWe for ; Wed, 8 Apr 2020 12:28:32 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5950D3A1619 for ; Wed, 8 Apr 2020 12:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6236; q=dns/txt; s=iport; t=1586374112; x=1587583712; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qF3gUCeyhW5wPXDBDFaWsxAx/QqfYrOqH4hHViokSX4=; b=E5JuXkcnPzxafWe+Dsldy246+yAX/68gKmCaJCB0+xZF31oj0BW/NBzz JlPV5/wk08qG2ViofQzOGU7kJ09bNfYFEx6TMidD+80DnsOPIC4TiGhMc DbOVqQC+gU6pAtw9j6YOR5Hk4vsBwGtxNlCMwp5K4B4EXbO3qA6ryMHdH 4=; X-IronPort-AV: E=Sophos;i="5.72,359,1580774400"; d="scan'208";a="747657608" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2020 19:27:54 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 038JRsro032188 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Apr 2020 19:27:54 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 14:27:53 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 15:27:52 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Apr 2020 14:27:52 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V2FzLVFa1V6tFc5tfV100ZB680S71t8vFK5uVhhZavWLgFxkPcU+RblN/8MLq+whKpUeaB6ebosME95Mgd0mUBVA5eLrLlwIiIPiYsmtLRsWXwpGz3Mz0hUtwkADpg/Cp7Dj47vViLyYwJ5RfvHeg012PkmRXaNPn48tl9E5Ihy+eot9kZ8toJdEjRwBbY+FK02LeksBYxAa9e5kArQCJTnbqRUyvBuhUTOFE6OhxbyWPpf8+8iFacKCWCAf5jMgV4rYuVlszAsUfuHuWpxam7sO4xuceaROgFeqwVT8oS17AneAaqWDFmcBEpHEGtXPEWOFdbXzjW5567HpNBYNHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qF3gUCeyhW5wPXDBDFaWsxAx/QqfYrOqH4hHViokSX4=; b=KBN7YmvHl4jaYtJIHomzRF2fUqjPn6j6552dgFMW+vf4e+dYztxHOEZIq+/4oz6p4bak8okECZxFQZtZ+fMmibokYnMa9wD1V/95Hzjqv9V/6nNMYL2caM8Y8+1/BPr/shX8EeJgqSwQy8UbkuIOWH8h+7MMxBd/HlWb5RlJU6QDGnc/n0kwCqOkcUlwCmdfDcbti6Be61Ze1hG9eRdQ8fdqj+ypdAjEWuLI9h6cNhNRohQ60dnaZxRvWagI05N3DmncQHy6t0ShXWdYb4RCSpoObaOi92XjGe1V/heM7ie2PkZbjQWmHL4kKFeBkcvFHPWLHwPotv8cZjD2bvc+WA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qF3gUCeyhW5wPXDBDFaWsxAx/QqfYrOqH4hHViokSX4=; b=qZeR95H2yKYjzg1PGPH48N8Ma9A666alzFiDbjuhbq59oZHucJVEuySwvEX3qcl+Xuw69FENi2SbEShcdVQvgTMTn/5qgSHuo6XV9WyDY5KIPJx47Cs7+yhdw6e3oNtGK4S65dzAK3M8F903daQ01QaspUSoIIJudTTE3o4tRnc= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2737.namprd11.prod.outlook.com (2603:10b6:406:b0::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Wed, 8 Apr 2020 19:27:51 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Wed, 8 Apr 2020 19:27:51 +0000 From: "Bernie Volz (volz)" To: "otroan@employees.org" , Ted Lemon CC: Fernando Gont , IPv6 Operations Thread-Topic: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes Thread-Index: AQHWDZ1XwKMiAc+bXU6k0lDVbIJuY6hvTjSggAAGxICAAC+AgIAABxUAgAAC2oCAAAGPgIAAA38AgAACLYCAAAPhAIAAAplw Date: Wed, 8 Apr 2020 19:27:51 +0000 Message-ID: References: <4E01DB76-DBF4-4B6D-B054-2A011E0AC3A6@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e99057d1-5f3b-4a73-46dc-08d7dbf2ede8 x-ms-traffictypediagnostic: BN7PR11MB2737: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(136003)(39860400002)(396003)(366004)(376002)(33656002)(7696005)(4326008)(81156014)(2906002)(8676002)(71200400001)(316002)(52536014)(53546011)(76116006)(6506007)(64756008)(66556008)(66446008)(66946007)(66476007)(86362001)(478600001)(5660300002)(186003)(8936002)(55016002)(54906003)(9686003)(26005)(966005)(81166007)(110136005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SZH77WB2qCTLFbDFHX8TMHEWWXpfNato8SRIi/XuQOIhe7vhwPTpDrmXzd/PFypPQ/9GY3itWZ9MX0+fvjbe83EOzfoRfksAFWNHNivU91VPeAm7xrCeXe5tRm2QYL4ouk/jtpuJcxFX4lAVrln6lCZheWjB2cQ2YuAswKrrkhrmWtmKI3VqJkD4Wviqcb92PW5fm7viKtSFcDszoCZRueHh5Zh99vZVsLTkj1X6zNoLUn32qa23sXz6X9SLmeaEpM8ZvOVD+nkdUDN2W0Bc6DmJeTojMrbAnhBdlvNZqcjjMesEPAIpu5Znx0e+hz6wc0+TCHd/nkxC7EnIQx+WIaQOnCFqCrxqyKywDtEg9PQMC52MBpQnL2BNhvdX/jP8Egm03xvye7KXQTL4lh/hFExejOFU4z5mEIEtd0VLlJYxpA1y0nDPgMX/aajsnZ9JUfrG25p9MX2Y6/9V7WXCgpJY+CAKnEPeFQLB9FptY3fgBniwGFzgxKe0K8PdajFwkDO5QOyTr1RiNOohvohC+g== x-ms-exchange-antispam-messagedata: H/JGCwszXaG7PJWYpJnF/Gn+i4+JeRNCsjoYsfs6+e2OTMEaD+2Fo9+xZN1+8uRPBWOws+IH6qgJUTV2XNg/1NaFqfbFycOlR+mLqk5GZ9bi0fLo0tSCWLS/Ujv67/9UpzBhQjXVrFP1+/5eWPfZBA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e99057d1-5f3b-4a73-46dc-08d7dbf2ede8 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 19:27:51.4456 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8EDZBVVpM02pSlBYsXJhDPUflnA6EOUyrh/+kiyYAWPgRfOfqLDY8Nv18QVr+vMM X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2737 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 19:28:39 -0000 PiBBbGwgZGVwbG95bWVudHMgSSBhbSBhd2FyZSBvZiB1c2UgdGhlIHJlbW90ZS1pZCAvIG9wdGlv bi04MiBlcXVpdmFsZW50IG9wdGlvbiB0byBpZGVudGlmeSBzdWJzY3JpYmVycw0KDQpZZXMsIHRo YXQgaWRlbnRpZmllcyB0aGUgc3Vic2NyaWJlci4gQnV0IHRoYXQgaXMgbm90IHRoZSBzYW1lIGFz IGlkZW50aWZ5aW5nIHRoZSBDUEUuIFdlIGRvLCBhZnRlciBhbGwsIGhhdmUgYSBjbGllbnQgaWRl bnRpZmllciBvcHRpb24gKDEpIHdoaWNoIGlzIGJhc2VkIG9uIHRoZSBEVUlELg0KDQotIEJlcm5p ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgPHY2b3BzLWJvdW5j ZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBvdHJvYW5AZW1wbG95ZWVzLm9yZw0KU2VudDogV2Vk bmVzZGF5LCBBcHJpbCA4LCAyMDIwIDM6MTggUE0NClRvOiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1 ZS5jb20+DQpDYzogRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPjsgSVB2NiBP cGVyYXRpb25zIDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIGNwZS1zbGFh Yy1yZW51bTogUHJvcG9zZWQgdGV4dCBmb3IgcHJlZml4IGxpZmV0aW1lcw0KDQo+Pj4+PiBwb3dl ciBjeWNsZWQuICBZb3UgcHJvYmFibHkgZG9u4oCZdCBfd2FudF8gdG8gdXNlIGxvbmcgVFRMcyBv biBkb21haW4gbmFtZXMsIGlmIGFueSBhcmUgcHVibGlzaGVk4oCUZS5nLiwgZm9yIG1ETlMgd2Ug dXNlIGEgVFRMIG9mIDc1IG1pbnV0ZXMsIGFuZCBkbyBhIHJlZnJlc2ggYXQgNjAgbWludXRlczsg d2UgZG8gdGhlIHNhbWUgdGhpbmcgZm9yIFNlcnZpY2UgUmVnaXN0cmF0aW9uIFByb3RvY29sIChE TlMgdXBkYXRlcyBmb3IgRE5TU0QpLCBhbHRob3VnaCB0aGF04oCZcyBub3Qgd2lkZWx5IGRlcGxv eWVkIGF0IHByZXNlbnQuDQo+Pj4+PiANCj4+Pj4+IFNvIGluIHRoaXMgY2FzZSwgd2hlcmUgeW91 ciBkZXZpY2UgbWF5IGJlIHBvd2VyIGN5Y2xlZCBhbmQgbG9zZSBpdHMgc3RhdGUsIG9yIHdoZXJl IHRoZSBlbmQgdXNlciBtYXkgc2ltcGx5IHVucGx1ZyBvbmUgZGV2aWNlIGFuZCBwbHVnIGluIGFu b3RoZXIsIGhhdmluZyBhIHJlYWxseSBsb25nIHByZWZlcnJlZCBsaWZldGltZSBtYWtlcyB6ZXJv IHNlbnNlLiAgT2J2aW91c2x5LCBoYXZpbmcgYSBzaG9ydGVyIGxpZmV0aW1lIGRvZXMgbm90IHNv bHZlIHRoZSBwcm9ibGVtIG9mIGNsZWFuaW5nIHVwIHN0YWxlIHByZWZpeGVzIGZhc3QgZW5vdWdo IHRvIHByZXZlbnQgcm91dGluZyBwcm9ibGVtcywgYnV0IHdlIHN0aWxsIHdhbnQgdGhvc2Ugc3Rh bGUgcHJlZml4ZXMgdG8gYmUgY2xlYW5lZCB1cC4gIEFzIHlvdSBzYXksIHRoZXJlIGFyZSB0d28g ZGlmZmVyZW50IGlzc3VlcyBoZXJlLiAgUmVhc29uYWJseSBzaG9ydCBhZGRyZXNzIGxpZmV0aW1l cyBhdm9pZHMga2VlcGluZyBhZGRyZXNzZXMgYXJvdW5kIGZvciBhIG1vbnRoIHdoZW4gdGhleSBh cmUgc3RhbGUgYW5kIGFyZW7igJl0IGdvaW5nIHRvIGJlIGV4cGxpY2l0bHkgZGVwcmVjYXRlZC4g IEZvciBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24gYW5kIHJvdXRlIHNlbGVjdGlvbiwgdGhpcyBk b2VzbuKAmXQgaGVscCwgYnV0IGl04oCZcyBzdGlsbCB3b3J0aCBkb2luZy4NCj4+Pj4+IA0KPj4+ PiANCj4+Pj4gWW91IHNlZW0gdG8gYmUgaW1wbHlpbmcgc29tZXRoaW5nIGhlcmUuDQo+Pj4+IFdo eSBkb2VzIGl0IG1hdHRlciBpZiBhIENQRSBpcyB1bnBsdWdnZWQgb3IgcG93ZXIgY3ljbGVkPyAo V2VsbCwgYXBhcnQgZnJvbSB0aGUgb2J2aW91cyBvZiBiZWluZyB1bmFibGUgdG8gZm9yd2FyZCBw YWNrZXRzIGZvciB0aGUgZHVyYXRpb24pLg0KPj4+IA0KPj4+IEl0IG1hdHRlcnMgaWYgdGhlIENQ RSBkb2VzbuKAmXQgbWFpbnRhaW4gc3RhdGUgYmV0d2VlbiBwb3dlciBjeWNsZXMsIGFuZCBnZXRz IGEgZGlmZmVyZW50IHByZWZpeCB3aGVuIGl0IGNvbWVzIGJhY2suIEFuZCBpdCBtYXR0ZXJzIGlm IHRoZSBDUEUgaXMgc3dhcHBlZCBvdXQgd2l0aG91dCBhIGNsZWFuIHNodXRkb3duIHRoYXQgd291 bGQgcmVzdWx0IGluIHRoZSBwcmVmaXggYmVpbmcgZGVwcmVjYXRlZCwgYW5kIHN1YnNlcXVlbnRs eSBnZXRzIGEgZGlmZmVyZW50IHByZWZpeCBmcm9tIHRoZSBJU1AuICAgSW4gYm90aCBvZiB0aGVz ZSBjYXNlcywgd2Ugd2FudCB0aGUgb2xkIHByZWZpeCB0byBnbyBhd2F5IHNvb25lciB0aGFuIGEg bW9udGguICBUaGlzIGRvZXNu4oCZdCBhYnNvbHZlIHVzIG9mIGhhdmluZyB0byBkbyB0aGUgd29y ayB0byBtYWtlIHN1cmUgdGhhdCB0aGluZ3Mgd29yayB3aGlsZSB0aGF0IHByZWZpeCBpcyBzdGls bCBwcmVzZW50LCBidXQgd2Ugc2hvdWxkIGFsc28gYmUgbGV0dGluZyBpdCBkaWUgY2xlYW5seS4N Cj4+PiANCj4+PiBJIHN1cHBvc2UgdGhlIGNvdW50ZXJhcmd1bWVudCB3b3VsZCBiZSB0aGF0IGlm IGl04oCZcyBzdGlsbCB2YWxpZCwgd2Ugc3RpbGwgd2FudCB0byB1c2UgaXQgZm9yIGV4aXN0aW5n IGNvbm5lY3Rpb25zLCBidXQgaXQgc2VlbXMgdW5saWtlbHkgdGhhdCB0aGlzIGNvdWxkIHdvcmsg aW4gZWl0aGVyIG9mIHRoZSBzaXR1YXRpb25zIEnigJltIGRlc2NyaWJpbmcuDQo+PiANCj4+IFJp Z2h0LCBzbyB0aGUgYnJva2VuIG9wZXJhdGlvbmFsIHByYWN0aWNlIG9mIGZsYXNoIHJlbnVtYmVy aW5nIHdpdGhvdXQgZGVwcmVjYXRpbmcgdGhlIG9sZCBwcmVmaXggYXBwcm9hY2ggdG8gUEQuDQo+ PiBMZXQncyBtYWtlIGNsZWFyIHRoYXQncyBuZWl0aGVyIHRoZSByZWNvbW1lbmRlZCBub3IgdGhl IHR5cGljYWwgd2F5IElTUHMgb3BlcmF0ZSB0aGVpciBuZXR3b3Jrcy4NCj4+IA0KPj4gSW4gYSB0 eXBpY2FseSBkZXBsb3ltZW50IHN3YXBwaW5nIENQRXMgb3IgcG93ZXIgY3ljbGluZyB0aGVtIGRv ZXMgb2YgY291cnNlIG5vdCBhZmZlY3QgdGhlIGRlbGVnYXRlZCBwcmVmaXguDQo+IA0KPiBJcyBp dCB0cnVlIHRoYXQgdGhpcyBpcyBmbGFzaCByZW51bWJlcmluZz8gIFdoZXJlIGluIHRoZSBQRCBz cGVjIGRvZXMgaXQgc2F5IHRoYXQgdGhlIHNlcnZlciBoYXMgdG8gZ2l2ZSB0aGUgc2FtZSBDUCAo Y3VzdG9tZXIgcHJlbWlzZXMpIHRoZSBzYW1lIHByZWZpeD8gIEhvdyBkb2VzIGl0IGlkZW50aWZ5 IHRoZSBDUCBpZiB0aGUgQ1BFIGhhcyBjaGFuZ2VkPyAgSSBrbm93IHRoYXQgdGhlcmUgYXJlIHdh eXMgdG8gZG8gdGhhdCwgYnV0IHRoZXJlIGlzIG5vIFJGQyBJIGtub3cgb2YgdGhhdCBzYXlzIGhv dyB0byBkbyB0aGF0LCBvciB0aGF0IHJlcXVpcmVzIHRoYXQgdGhpcyBiZSBkb25lLg0KPiANCj4g RG9lcyB0aGUgUEQgc3BlYyBzYXkgdGhhdCB0aGUgSVNQIGhhcyB0byBnaXZlIHRoZSBDUEUgdGhl IHNhbWUgcHJlZml4LCBhc3N1bWluZyB0aGF0IGl0IF9jYW5fIGlkZW50aWZ5IGl0Pw0KPiANCj4g QXMgSSBzYWlkIGVhcmxpZXIsIEkgdGhpbmsgaXTigJlzIHRoZSBjYXNlIHRoYXQgaWYgYSBQRCBp cyBpc3N1ZWQsIHRoZSBESENQIHNlcnZlciBoYXMgdG8gaG9ub3IgaXQgdW50aWwgaXTigJlzIG5v IGxvbmdlciB2YWxpZCwgYnV0IHVubGVzcyB3ZSByZXF1aXJlIHRoYXQgaXQgcmV0dXJuIHRoZSBz YW1lIHByZWZpeCBpbiB0aGlzIGNhc2Ugd2hlbiB0aGUgQ1BFIGRldmljZSBkb2VzbuKAmXQgZXhw bGljaXRseSBhc2sgZm9yIGl0LCB0aGVyZSBpcyBhIHNpZ25pZmljYW50IGdhcCBoZXJlLg0KDQpT b3JyeSwgSSBkb24ndCBzZWUgdGhlIGdhcC4NCkFsbCBkZXBsb3ltZW50cyBJIGFtIGF3YXJlIG9m IHVzZSB0aGUgcmVtb3RlLWlkIC8gb3B0aW9uLTgyIGVxdWl2YWxlbnQgb3B0aW9uIHRvIGlkZW50 aWZ5IHN1YnNjcmliZXJzLg0KTW9zdCBvcGVyYXRvcnMgYXJlIGEgbG90IG1vcmUgY2x1ZWZ1bCBh Ym91dCB0aGlzIHRoYW4gdXMgaGVyZS4NCg0KVGhpbmsgb2YgUEQgYXMgYSBjb250cmFjdC4gVGhl IElTUCBwcm9taXNlcyB0byBsZWFzZSB0aGUgcHJlZml4IHRvIHRoZSBzdWJzY3JpYmVyIGZvciB0 aGUgdGltZSBzdGF0ZWQuDQpUaGUgSVNQIGNhbiBzdGlsbCBkbyBmbGFzaCByZW51bWJlcmluZyAo YWx0aG91Z2ggdGhhdCdzIGxpa2VseSB0byBpbmR1Y2UgYSBjdXN0b21lciBjYWxsKSBpbiB0d28g d2F5cy4NCk9uZSwganVzdCBpZ25vcmUgaXQncyBlYXJsaWVyIHByb21pc2UgYW5kIGdpdmUgdGhl IHN1YnNjcmliZXIgYSBuZXcgcHJlZml4ICh3aGljaCBpbnRyb2R1Y2VzIGFsbCB0aGUgcHJvYmxl bXMgRmVybmFkbyB3YW50cyB0byB1c2UgcHJlZml4IGxpZmV0aW1lcyB0byBzb2x2ZSksIG9yIGl0 IGNhbiBpbmNsdWRlIHRoZSBvbGQgcHJlZml4IHdpdGggbGlmZXRpbWVzIDAgKHZpb2xhdGluZyBp dCdzIGVhcmxpZXIgcHJvbWlzZSwgYnV0IGF0IGxlYXN0IGJlaW5nIGV4cGxpY2l0KSBhbmQgYWR2 ZXJ0aXNlIGEgbmV3IHByZWZpeC4NCg0KQ2hlZXJzLA0KT2xlDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Wed Apr 8 12:30:05 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C9A3A1641 for ; Wed, 8 Apr 2020 12:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAHYr0jPCIkK for ; Wed, 8 Apr 2020 12:30:02 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB5E3A163F for ; Wed, 8 Apr 2020 12:30:01 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 3399B831C9; Wed, 8 Apr 2020 21:29:58 +0200 (CEST) To: otroan@employees.org Cc: Ted Lemon , IPv6 Operations References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> <5AACFB5F-D67D-4779-B5EB-E6D8A58516F7@fugue.com> <28b956ea-2f7c-ffbf-4920-ea975df0f0f9@si6networks.com> <6D3632A9-30CF-4D0A-A7FF-E2CDD6EAA2EB@employees.org> From: Fernando Gont Message-ID: Date: Wed, 8 Apr 2020 16:29:51 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <6D3632A9-30CF-4D0A-A7FF-E2CDD6EAA2EB@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 19:30:04 -0000 On 8/4/20 16:20, otroan@employees.org wrote: [...] >>>> I suppose the counterargument would be that if it’s still valid, we still want to use it for existing connections, but it seems unlikely that this could work in either of the situations I’m describing. >>> Right, so the broken operational practice of flash renumbering without deprecating the old prefix approach to PD. >>> Let's make clear that's neither the recommended nor the typical way ISPs operate their network >> This seems to disagree with your claim: https://indico.uknof.org.uk/event/41/contributions/542/attachments/712/866/bcop-ipv6-prefix-v9.pdf > > That presentation recommends persistent prefixes. My point exactly. You seem to read what you want to read: this presentation that 37% of the responding ISPs employ dynamic prefixes. Yes, the presentation recommends stable prefixes. -- we also recommend IPv6 deployment (such recommendation hasn't avoided the problem we are trying to solve, in a similar vein that our recomendation to deploy IPv6 hasn't materialized as expected). Reality check? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Apr 8 12:32:20 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F143A1650 for ; Wed, 8 Apr 2020 12:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lCRt7z6X; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=G+vuhMsx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8Y7L-7J4E7c for ; Wed, 8 Apr 2020 12:32:15 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A458E3A1657 for ; Wed, 8 Apr 2020 12:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7238; q=dns/txt; s=iport; t=1586374335; x=1587583935; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2zmBnMsIkV487sxDB0tc77OdfoGcz6YcRSHNuV8FDLM=; b=lCRt7z6XK494LEngzCjlQ8qakMZnfNRQHHXWvf+7hf1OKCJTQwdEZya3 /nylRp0oGJLHG1CK0fQIXj57lSklwhwINWyX+tf2xc4M0IuHWCJtQkfn3 JpY1hJh0riekkyoOcU/f5sQf/3BpKGJU17FqcFyz9WYBNMV1FFeVOpoX7 o=; IronPort-PHdr: =?us-ascii?q?9a23=3A/swYpRIvsjOF/mw2admcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCuKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZubDknpBPXrdCc9Ws9FUQwt8g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAABIJo5e/4kNJK1cChoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBagIBAQEBCwGBU1AFbFggBAsqCoQSg0UDimq?= =?us-ascii?q?CX5ggglIDVAoBAQEMAQEYCwoCBAEBhEQCF4FwJDcGDgIDAQELAQEFAQEBAgE?= =?us-ascii?q?FBG2FVgyFcAEBAQECAQEBEBERDAEBLAsBBAcEAgEIEQQBAQMCJgICAiULFQg?= =?us-ascii?q?IAgQBDQUIGoMFgksDDiABDqVnAoE5iGJ1gTKCfwEBBYEvAYQjGIINAwaBDio?= =?us-ascii?q?BjDIaggCBEUOCTT6CZwEBgTgPBhqDEDKCLJENoCcKgj2XUpwIiwc9g3icKwI?= =?us-ascii?q?EAgQFAg4BAQWBaCOBV3AVO4JpUBgNkSIMF4NQhRSFQXSBKY0ZATBfAQE?= X-IronPort-AV: E=Sophos;i="5.72,359,1580774400"; d="scan'208";a="754936802" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2020 19:32:14 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 038JWEFh002924 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Apr 2020 19:32:14 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 14:32:14 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 14:32:13 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Apr 2020 15:32:13 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L8ZCDIlS0VGS5fbXSYcS78xZNrypYZA56n8Hm0kESKPsVh/mIAsOQHIvE7MmHrsZxCe6JKoAJZLdBY7yKTPtIZdGPi3hmUtucOAUHfec9e2OhGjdD/kj+kd4FrRQdiqzHCrw9Jl7+98m4jdIlqiusX2O2F1S2hmLY0ecoZQ6xtRwJk6viUJrUbc6P9/+Q5Gt5MyARxbZO74bPdo675qhQ6w9+Qj4bToTcBrfYSTUXKdviE6NTP+5+cPUOJNUOIncmWsk9Q8IlUkwJgm3wktJpdmsgqIoyN1ESQIGFFzkVqOkVqe5BAViX+aZ5IK4BiknxN8arGmVw3WKZ5dx05L4dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2zmBnMsIkV487sxDB0tc77OdfoGcz6YcRSHNuV8FDLM=; b=U0BgvKEC90RjDFLZufZsbGq2JbAKw+py86anorH5IVrVHmDuL0gD1xAl8XYybPuhARNhYeTkUDSG4v9xzasPWmNEWtuG3TY4hdjWcWBkGFhF5XpTHWMVWvPcBxxp7+OCq2A+YUcQmweyCabiiaIipcvut6ECGe+L9gbDG+W+Id30hwpg+LXTGjm1JPS4PgltDqwmewTGbgzIKc9mBkQqtQXBiwWD3dS7Grdsk1lIKLJ9OSE606M43NIr/R1VyG8QBrtA1IviwffjqkZeNNHZLtNbqOATZi8+EhAoKZxTo5JeHOAeNwIe0AfYfRHolvBaoVP0NVxXSE1dFEj2Bfy4GQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2zmBnMsIkV487sxDB0tc77OdfoGcz6YcRSHNuV8FDLM=; b=G+vuhMsxu3fwEf5OxWiudg7ckOnxNOr5+aUQEC2vfL6Km6HaNKWhmAxkWWb2/ybaYjjBO/OcfbitsBDvjBc3TelHc4o9OoBJ+w9tzz8enBWuG0Xs+6OeP7bCHQt3109QhNnbS6ukxU5l6g3VlREFACUNNM59gvWcHOCeWwWQ/oY= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2625.namprd11.prod.outlook.com (2603:10b6:406:b9::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Wed, 8 Apr 2020 19:32:11 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Wed, 8 Apr 2020 19:32:11 +0000 From: "Bernie Volz (volz)" To: "otroan@employees.org" , Ted Lemon CC: Fernando Gont , IPv6 Operations Thread-Topic: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes Thread-Index: AQHWDZ1XwKMiAc+bXU6k0lDVbIJuY6hvTjSggAAGxICAAC+AgIAABxUAgAAC2oCAAAGPgIAAA38AgAACLYCAAAPhAIAAAplwgAAA2PA= Date: Wed, 8 Apr 2020 19:32:11 +0000 Message-ID: References: <4E01DB76-DBF4-4B6D-B054-2A011E0AC3A6@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0ad9e2d-f727-41bc-3bf1-08d7dbf38900 x-ms-traffictypediagnostic: BN7PR11MB2625: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(366004)(396003)(136003)(346002)(376002)(86362001)(26005)(81156014)(7696005)(9686003)(71200400001)(53546011)(8936002)(6506007)(2940100002)(966005)(478600001)(2906002)(33656002)(66446008)(52536014)(55016002)(54906003)(5660300002)(316002)(81166007)(8676002)(4326008)(64756008)(186003)(66556008)(66476007)(110136005)(66946007)(76116006); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jx81svPcU7CuAntwS1kqMokV/L4r5t7DOP4vBZjBGyZERucXGuRZDM+Cxsvf6WEys4Qt359nN4dQmecy7jzf6iPwR1YqXKnQJrhOMmxYldH/rZXt5fh6XcTArpXN/BhgdfU9M0LZ+W5Kt1XRpVkTzbS4il4CNqcqv+41MiGHw+44oFmMZQZq7OR1Dej7nit994bV4mtKN6ksyw3dzKAYsmYGxom4F9O87jl+RWAtqvbFfSZBuE8sFgb4aBldV658B5gi2u9HIRqfplJFBieY9ktcAJzqm+O/udz454RQCbe7+K9VjtN320sxNvLbKJOkLwaikuQHbJdDzPHLsGczCniyxav8vKY85dnk3wkREWx4MeIst953zoN+mHSf1gvM2GnahTVLI7QHUiDuXtDhKYGQQeZbmGJmRox1puTtk1TLDAZnHSLteO8/JqFXKWxGET2m2h7y5I0rcQhsTucyVHVzc1KS+lF/lk0GoflLQhVfgMAwGmsU3LvNmgEWMqbqPpuo5qph87ywwcXJ10un9Q== x-ms-exchange-antispam-messagedata: KSyICmGRXOEI/JejYDWBM15JgJn7nAlzLH64magh+vWEDeRZfGhF/Gmh06I07UfQQTArNEaVOQbp490BoIBYff+Bu+d2Kr4jpVJiqsK+WNlcKZIFXf21zvHJU9KX2PcYJvodr5kc+P/9jASYY9zKmQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e0ad9e2d-f727-41bc-3bf1-08d7dbf38900 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 19:32:11.7164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: q1BDTon6lwybR4x8R21bm2bMGgOIdU01j4McWyu/52XMSct2m6TlKcDCUDONe3c3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2625 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 19:32:18 -0000 QW5kLCBJIHNob3VsZCBoYXZlIGFkZGVkIC4uLiBob3cgZG9lcyB0aGUgU1Aga25vdyB0aGF0IHlv dSByZXBsYWNlZCB5b3VyIENQRSBpbnN0ZWFkIG9mIGFkZGluZyBhIHNlY29uZC4NCg0KQXQgbGVh c3QgaW4gc29tZSBkZXBsb3ltZW50cyAoc3VjaCBhcyBET0NTSVMpIHRoZXJlJ3Mgbm90aGluZyBu ZWNlc3NhcmlseSB0aGF0IHByZWNsdWRlcyB5b3UgZnJvbSBoYXZpbmcgbXVsdGlwbGUgQ1BFcyBi ZWhpbmQgYSBDTS4NCg0KLSBCZXJuaWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQmVybmllIFZv bHogKHZvbHopDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDgsIDIwMjAgMzoyOCBQTQ0KVG86IG90 cm9hbkBlbXBsb3llZXMub3JnOyBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+DQpDYzogRmVy bmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPjsgSVB2NiBPcGVyYXRpb25zIDx2Nm9w c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIGNwZS1zbGFhYy1yZW51bTogUHJvcG9z ZWQgdGV4dCBmb3IgcHJlZml4IGxpZmV0aW1lcw0KDQo+IEFsbCBkZXBsb3ltZW50cyBJIGFtIGF3 YXJlIG9mIHVzZSB0aGUgcmVtb3RlLWlkIC8gb3B0aW9uLTgyIGVxdWl2YWxlbnQgb3B0aW9uIHRv IGlkZW50aWZ5IHN1YnNjcmliZXJzDQoNClllcywgdGhhdCBpZGVudGlmaWVzIHRoZSBzdWJzY3Jp YmVyLiBCdXQgdGhhdCBpcyBub3QgdGhlIHNhbWUgYXMgaWRlbnRpZnlpbmcgdGhlIENQRS4gV2Ug ZG8sIGFmdGVyIGFsbCwgaGF2ZSBhIGNsaWVudCBpZGVudGlmaWVyIG9wdGlvbiAoMSkgd2hpY2gg aXMgYmFzZWQgb24gdGhlIERVSUQuDQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9m IG90cm9hbkBlbXBsb3llZXMub3JnDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDgsIDIwMjAgMzox OCBQTQ0KVG86IFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbT4NCkNjOiBGZXJuYW5kbyBHb250 IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+OyBJUHY2IE9wZXJhdGlvbnMgPHY2b3BzQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFt2Nm9wc10gY3BlLXNsYWFjLXJlbnVtOiBQcm9wb3NlZCB0ZXh0IGZv ciBwcmVmaXggbGlmZXRpbWVzDQoNCj4+Pj4+IHBvd2VyIGN5Y2xlZC4gIFlvdSBwcm9iYWJseSBk b27igJl0IF93YW50XyB0byB1c2UgbG9uZyBUVExzIG9uIGRvbWFpbiBuYW1lcywgaWYgYW55IGFy ZSBwdWJsaXNoZWTigJRlLmcuLCBmb3IgbUROUyB3ZSB1c2UgYSBUVEwgb2YgNzUgbWludXRlcywg YW5kIGRvIGEgcmVmcmVzaCBhdCA2MCBtaW51dGVzOyB3ZSBkbyB0aGUgc2FtZSB0aGluZyBmb3Ig U2VydmljZSBSZWdpc3RyYXRpb24gUHJvdG9jb2wgKEROUyB1cGRhdGVzIGZvciBETlNTRCksIGFs dGhvdWdoIHRoYXTigJlzIG5vdCB3aWRlbHkgZGVwbG95ZWQgYXQgcHJlc2VudC4NCj4+Pj4+IA0K Pj4+Pj4gU28gaW4gdGhpcyBjYXNlLCB3aGVyZSB5b3VyIGRldmljZSBtYXkgYmUgcG93ZXIgY3lj bGVkIGFuZCBsb3NlIGl0cyBzdGF0ZSwgb3Igd2hlcmUgdGhlIGVuZCB1c2VyIG1heSBzaW1wbHkg dW5wbHVnIG9uZSBkZXZpY2UgYW5kIHBsdWcgaW4gYW5vdGhlciwgaGF2aW5nIGEgcmVhbGx5IGxv bmcgcHJlZmVycmVkIGxpZmV0aW1lIG1ha2VzIHplcm8gc2Vuc2UuICBPYnZpb3VzbHksIGhhdmlu ZyBhIHNob3J0ZXIgbGlmZXRpbWUgZG9lcyBub3Qgc29sdmUgdGhlIHByb2JsZW0gb2YgY2xlYW5p bmcgdXAgc3RhbGUgcHJlZml4ZXMgZmFzdCBlbm91Z2ggdG8gcHJldmVudCByb3V0aW5nIHByb2Js ZW1zLCBidXQgd2Ugc3RpbGwgd2FudCB0aG9zZSBzdGFsZSBwcmVmaXhlcyB0byBiZSBjbGVhbmVk IHVwLiAgQXMgeW91IHNheSwgdGhlcmUgYXJlIHR3byBkaWZmZXJlbnQgaXNzdWVzIGhlcmUuICBS ZWFzb25hYmx5IHNob3J0IGFkZHJlc3MgbGlmZXRpbWVzIGF2b2lkcyBrZWVwaW5nIGFkZHJlc3Nl cyBhcm91bmQgZm9yIGEgbW9udGggd2hlbiB0aGV5IGFyZSBzdGFsZSBhbmQgYXJlbuKAmXQgZ29p bmcgdG8gYmUgZXhwbGljaXRseSBkZXByZWNhdGVkLiAgRm9yIHNvdXJjZSBhZGRyZXNzIHNlbGVj dGlvbiBhbmQgcm91dGUgc2VsZWN0aW9uLCB0aGlzIGRvZXNu4oCZdCBoZWxwLCBidXQgaXTigJlz IHN0aWxsIHdvcnRoIGRvaW5nLg0KPj4+Pj4gDQo+Pj4+IA0KPj4+PiBZb3Ugc2VlbSB0byBiZSBp bXBseWluZyBzb21ldGhpbmcgaGVyZS4NCj4+Pj4gV2h5IGRvZXMgaXQgbWF0dGVyIGlmIGEgQ1BF IGlzIHVucGx1Z2dlZCBvciBwb3dlciBjeWNsZWQ/IChXZWxsLCBhcGFydCBmcm9tIHRoZSBvYnZp b3VzIG9mIGJlaW5nIHVuYWJsZSB0byBmb3J3YXJkIHBhY2tldHMgZm9yIHRoZSBkdXJhdGlvbiku DQo+Pj4gDQo+Pj4gSXQgbWF0dGVycyBpZiB0aGUgQ1BFIGRvZXNu4oCZdCBtYWludGFpbiBzdGF0 ZSBiZXR3ZWVuIHBvd2VyIGN5Y2xlcywgYW5kIGdldHMgYSBkaWZmZXJlbnQgcHJlZml4IHdoZW4g aXQgY29tZXMgYmFjay4gQW5kIGl0IG1hdHRlcnMgaWYgdGhlIENQRSBpcyBzd2FwcGVkIG91dCB3 aXRob3V0IGEgY2xlYW4gc2h1dGRvd24gdGhhdCB3b3VsZCByZXN1bHQgaW4gdGhlIHByZWZpeCBi ZWluZyBkZXByZWNhdGVkLCBhbmQgc3Vic2VxdWVudGx5IGdldHMgYSBkaWZmZXJlbnQgcHJlZml4 IGZyb20gdGhlIElTUC4gICBJbiBib3RoIG9mIHRoZXNlIGNhc2VzLCB3ZSB3YW50IHRoZSBvbGQg cHJlZml4IHRvIGdvIGF3YXkgc29vbmVyIHRoYW4gYSBtb250aC4gIFRoaXMgZG9lc27igJl0IGFi c29sdmUgdXMgb2YgaGF2aW5nIHRvIGRvIHRoZSB3b3JrIHRvIG1ha2Ugc3VyZSB0aGF0IHRoaW5n cyB3b3JrIHdoaWxlIHRoYXQgcHJlZml4IGlzIHN0aWxsIHByZXNlbnQsIGJ1dCB3ZSBzaG91bGQg YWxzbyBiZSBsZXR0aW5nIGl0IGRpZSBjbGVhbmx5Lg0KPj4+IA0KPj4+IEkgc3VwcG9zZSB0aGUg Y291bnRlcmFyZ3VtZW50IHdvdWxkIGJlIHRoYXQgaWYgaXTigJlzIHN0aWxsIHZhbGlkLCB3ZSBz dGlsbCB3YW50IHRvIHVzZSBpdCBmb3IgZXhpc3RpbmcgY29ubmVjdGlvbnMsIGJ1dCBpdCBzZWVt cyB1bmxpa2VseSB0aGF0IHRoaXMgY291bGQgd29yayBpbiBlaXRoZXIgb2YgdGhlIHNpdHVhdGlv bnMgSeKAmW0gZGVzY3JpYmluZy4NCj4+IA0KPj4gUmlnaHQsIHNvIHRoZSBicm9rZW4gb3BlcmF0 aW9uYWwgcHJhY3RpY2Ugb2YgZmxhc2ggcmVudW1iZXJpbmcgd2l0aG91dCBkZXByZWNhdGluZyB0 aGUgb2xkIHByZWZpeCBhcHByb2FjaCB0byBQRC4NCj4+IExldCdzIG1ha2UgY2xlYXIgdGhhdCdz IG5laXRoZXIgdGhlIHJlY29tbWVuZGVkIG5vciB0aGUgdHlwaWNhbCB3YXkgSVNQcyBvcGVyYXRl IHRoZWlyIG5ldHdvcmtzLg0KPj4gDQo+PiBJbiBhIHR5cGljYWx5IGRlcGxveW1lbnQgc3dhcHBp bmcgQ1BFcyBvciBwb3dlciBjeWNsaW5nIHRoZW0gZG9lcyBvZiBjb3Vyc2Ugbm90IGFmZmVjdCB0 aGUgZGVsZWdhdGVkIHByZWZpeC4NCj4gDQo+IElzIGl0IHRydWUgdGhhdCB0aGlzIGlzIGZsYXNo IHJlbnVtYmVyaW5nPyAgV2hlcmUgaW4gdGhlIFBEIHNwZWMgZG9lcyBpdCBzYXkgdGhhdCB0aGUg c2VydmVyIGhhcyB0byBnaXZlIHRoZSBzYW1lIENQIChjdXN0b21lciBwcmVtaXNlcykgdGhlIHNh bWUgcHJlZml4PyAgSG93IGRvZXMgaXQgaWRlbnRpZnkgdGhlIENQIGlmIHRoZSBDUEUgaGFzIGNo YW5nZWQ/ICBJIGtub3cgdGhhdCB0aGVyZSBhcmUgd2F5cyB0byBkbyB0aGF0LCBidXQgdGhlcmUg aXMgbm8gUkZDIEkga25vdyBvZiB0aGF0IHNheXMgaG93IHRvIGRvIHRoYXQsIG9yIHRoYXQgcmVx dWlyZXMgdGhhdCB0aGlzIGJlIGRvbmUuDQo+IA0KPiBEb2VzIHRoZSBQRCBzcGVjIHNheSB0aGF0 IHRoZSBJU1AgaGFzIHRvIGdpdmUgdGhlIENQRSB0aGUgc2FtZSBwcmVmaXgsIGFzc3VtaW5nIHRo YXQgaXQgX2Nhbl8gaWRlbnRpZnkgaXQ/DQo+IA0KPiBBcyBJIHNhaWQgZWFybGllciwgSSB0aGlu ayBpdOKAmXMgdGhlIGNhc2UgdGhhdCBpZiBhIFBEIGlzIGlzc3VlZCwgdGhlIERIQ1Agc2VydmVy IGhhcyB0byBob25vciBpdCB1bnRpbCBpdOKAmXMgbm8gbG9uZ2VyIHZhbGlkLCBidXQgdW5sZXNz IHdlIHJlcXVpcmUgdGhhdCBpdCByZXR1cm4gdGhlIHNhbWUgcHJlZml4IGluIHRoaXMgY2FzZSB3 aGVuIHRoZSBDUEUgZGV2aWNlIGRvZXNu4oCZdCBleHBsaWNpdGx5IGFzayBmb3IgaXQsIHRoZXJl IGlzIGEgc2lnbmlmaWNhbnQgZ2FwIGhlcmUuDQoNClNvcnJ5LCBJIGRvbid0IHNlZSB0aGUgZ2Fw Lg0KQWxsIGRlcGxveW1lbnRzIEkgYW0gYXdhcmUgb2YgdXNlIHRoZSByZW1vdGUtaWQgLyBvcHRp b24tODIgZXF1aXZhbGVudCBvcHRpb24gdG8gaWRlbnRpZnkgc3Vic2NyaWJlcnMuDQpNb3N0IG9w ZXJhdG9ycyBhcmUgYSBsb3QgbW9yZSBjbHVlZnVsIGFib3V0IHRoaXMgdGhhbiB1cyBoZXJlLg0K DQpUaGluayBvZiBQRCBhcyBhIGNvbnRyYWN0LiBUaGUgSVNQIHByb21pc2VzIHRvIGxlYXNlIHRo ZSBwcmVmaXggdG8gdGhlIHN1YnNjcmliZXIgZm9yIHRoZSB0aW1lIHN0YXRlZC4NClRoZSBJU1Ag Y2FuIHN0aWxsIGRvIGZsYXNoIHJlbnVtYmVyaW5nIChhbHRob3VnaCB0aGF0J3MgbGlrZWx5IHRv IGluZHVjZSBhIGN1c3RvbWVyIGNhbGwpIGluIHR3byB3YXlzLg0KT25lLCBqdXN0IGlnbm9yZSBp dCdzIGVhcmxpZXIgcHJvbWlzZSBhbmQgZ2l2ZSB0aGUgc3Vic2NyaWJlciBhIG5ldyBwcmVmaXgg KHdoaWNoIGludHJvZHVjZXMgYWxsIHRoZSBwcm9ibGVtcyBGZXJuYWRvIHdhbnRzIHRvIHVzZSBw cmVmaXggbGlmZXRpbWVzIHRvIHNvbHZlKSwgb3IgaXQgY2FuIGluY2x1ZGUgdGhlIG9sZCBwcmVm aXggd2l0aCBsaWZldGltZXMgMCAodmlvbGF0aW5nIGl0J3MgZWFybGllciBwcm9taXNlLCBidXQg YXQgbGVhc3QgYmVpbmcgZXhwbGljaXQpIGFuZCBhZHZlcnRpc2UgYSBuZXcgcHJlZml4Lg0KDQpD aGVlcnMsDQpPbGUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Wed Apr 8 12:32:26 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A33F3A1685 for ; Wed, 8 Apr 2020 12:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 TIFZI-Edfbxb for ; Wed, 8 Apr 2020 12:32:20 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57323A165C for ; Wed, 8 Apr 2020 12:32:20 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id z15so1499460qki.7 for ; Wed, 08 Apr 2020 12:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=SAHcDPiidC6JA6RspY1TGircCsmnK80YSj560J3bboY=; b=kBF5xgHj3ral/31ePoCDcNIEYVoOGymGMb2onykhlcroPH/k7HpmU8pm3bT85xNegI mQwy3EAPstf5MEwG+/V+OaWJxpCOT3W4NfMAFn2ABnduUjisI9dj/n91N8aeHcKvtyIM GLieyfwLio6Gye8tJcNDSjb7u46T4VbcIrXX1bvFWiuMWqEL+Cdi2dZAlKlyGa/c6QfZ Xl7MGhJpGzqUGafQnyPVenqFtw80E1Ad7shSqclZJQMpWOddPTsLmjtvBaeaM2p9BFhl OVhRNw4eRa2/qpMAom2ZnQg57r5grqW1IfslHrl6aLtKeUohh9qBg0nG2Q5nT8fbP2Nz gP6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=SAHcDPiidC6JA6RspY1TGircCsmnK80YSj560J3bboY=; b=As5aGH6lbAApIMvLlhgKRXHKXFiN5rvrdKI45CbYJMyYcAb83butsez9VAvnd8V6O/ 6ZEaRJO3aoALd0GMXCCuX03kR4/jOGMJUW+3knALjLiC9xOQGIA1Znm02c/uS7GgAOHi tX3sYyR+q3i6FNHXj/76x2JE83n1Qg38qRiwLsqSqkr9snkJcYxosAqJCHmwdLDF6Wlk YOLC4zcCapF4ZBcotZaApvA8JywUeh9fiLTWQlKSxL5oK6tJikWotLankllQNDoOT+x3 MgSEX9UaZgJ9STLiU5Zlin+GqL5jJhMbVY4uKUyp7A4N595ZDN1p7ev/uphhE9OlNx57 yPhg== X-Gm-Message-State: AGi0PuaFgKMcD7viLAoql4vumD9s8amud/x90oorLmOizVb0D/JWw20j ulfQb5OvmmoNolVA53cLpg3kug== X-Google-Smtp-Source: APiQypKdHAzHGb3pOFYbGwPhRPjp7B2827p+8fPGBR1SqzqXFHI3xDirv68JS9N6c9Zc/cy2+RBdzg== X-Received: by 2002:a37:7783:: with SMTP id s125mr8927632qkc.492.1586374339489; Wed, 08 Apr 2020 12:32:19 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:201b:83ea:1756:69e4? ([2601:18b:300:36ee:201b:83ea:1756:69e4]) by smtp.gmail.com with ESMTPSA id q186sm9536654qke.12.2020.04.08.12.32.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Apr 2020 12:32:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 8 Apr 2020 15:32:18 -0400 Message-Id: <91E3C450-57C9-4809-B4F3-B6210F27E09C@fugue.com> References: Cc: Fernando Gont , IPv6 Operations In-Reply-To: To: otroan@employees.org X-Mailer: iPad Mail (17E255) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 19:32:24 -0000 > Sorry, I don't see the gap. > All deployments I am aware of use the remote-id / option-82 equivalent opt= ion to identify subscribers. > Most operators are a lot more clueful about this than us here. >=20 > Think of PD as a contract. The ISP promises to lease the prefix to the sub= scriber for the time stated. > The ISP can still do flash renumbering (although that's likely to induce a= customer call) in two ways. > One, just ignore it's earlier promise and give the subscriber a new prefix= (which introduces all the problems Fernado wants to use prefix lifetimes to= solve), or it can include the old prefix with lifetimes 0 (violating it's e= arlier promise, but at least being explicit) and advertise a new prefix. I=E2=80=99m trying to figure out why this is such an utterly unsatisfying re= sponse. Yes, I get that in the ideal case, which is what you are describing= here, there is no problem. But you are missing _all_ of the edge cases. A= nd you=E2=80=99re assuming that things on a home network are a lot cleaner t= han I think is safe to assume. So yes, in the case you describe, where everything is done correctly, there i= s no problem. I would not expect to see the persistent prefix problem routi= nely. But I think it=E2=80=99s worth designing for=E2=80=94there are a lot o= f reasons why renumbering might happen in a way that is not as clean as you=E2= =80=99re saying it should be, and we ought to handle it gracefully when it h= appens.= From nobody Wed Apr 8 12:40:19 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DA63A166E for ; Wed, 8 Apr 2020 12:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ucd-ie.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 qJjPzQe3KcLM for ; Wed, 8 Apr 2020 12:40:15 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704653A1644 for ; Wed, 8 Apr 2020 12:40:15 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id d202so844235wmd.1 for ; Wed, 08 Apr 2020 12:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=yxCdzSnqMvi1Fp/4V2CLH+XHkj0Ux9yobS189W5Qp38=; b=umae99qQIR6WVoVtdq/IJDQZrjpZP0nuOFZmXPfgjkjZ5ZGAYqHNWSpJFw4PubRmN3 1/TVam2XbTc7IOPZ3B3sSjuTzBpXmx5pmX/hUHNDAQEg0HP6sAPLLmsWJmBf2Vz1n9kv J3YIGan6Vpy/1SMHhz9eE92g4Q59Ipk3dNMnvBxJ9U/SaehrUy7OiluHE3LGzNBeBur/ IunXWl1Je/zyupuAyWO6UXdy4PnO+FA1kz+AT9Ul9yHAcMoLysar/eIzlmcBdjvTb+vl nJk/gTS5W2si9Rqgrdxsn8J2jmD/5Sm4cSGzy6qPFDvNH3zBG7wtmOmJ8UesDKcstcUM GUJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=yxCdzSnqMvi1Fp/4V2CLH+XHkj0Ux9yobS189W5Qp38=; b=QQUDrrvWAzD0bSz6EylrUIKaZfwFFXvTxVy5V4Lx424LI5ugOilo58yr+sSDbCiIKW BG8ggaQWyzAu7PBTENiH5Dsbiri0dEzeHweCH3rcjSErAaXCLDTN8ZcB8ysC37y4FjaN EIYpEjm4EoJQTJMTIqclOHQjvjSJRzf4PJbQTW4kYYrqueK+mRuSqOydOlxEQCES05Fb kcYNxJdTpCS5lBG9Yrz0tEPNBW54QDeJk1gbfVCIxNd62fbfwsmlbKliLDvWayk5rq/E BXJNm9rWLnl6WVuUAzc7orlI18Xg9Pw9l/T4vRrx8GBCFZqSvYOYo0GkQRhvAE0XgD4N U4Dw== X-Gm-Message-State: AGi0Pubsg75JYb27n77BfYrgDri+wwLqA/vIXN1thN/Kp0D6hl9pGBmY JKlTyFmN3x7bw0n0bI6wEsDUO7jKgfo= X-Google-Smtp-Source: APiQypLfEQQUyt3oDTVpWOjwO2GwZ7OoFU0pJqDqz97bKeM+OahmDsBxwtPNmxAp5bJ5RCbpTYVqmg== X-Received: by 2002:a1c:44b:: with SMTP id 72mr3448956wme.58.1586374813319; Wed, 08 Apr 2020 12:40:13 -0700 (PDT) Received: from [10.0.1.161] (51-171-168-173-dynamic.agg2.blb.cld-dbn.eircom.net. [51.171.168.173]) by smtp.gmail.com with ESMTPSA id j124sm653275wmb.25.2020.04.08.12.40.10 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2020 12:40:12 -0700 (PDT) From: "Niall O'Reilly" X-Google-Original-From: "Niall O'Reilly" To: "IPv6 Operations" Date: Wed, 08 Apr 2020 20:40:09 +0100 X-Mailer: MailMate (1.13.1r5671) Message-ID: <1E67F361-9E86-4751-AD77-FDA6777C5571@ucd.ie> In-Reply-To: References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> <5AACFB5F-D67D-4779-B5EB-E6D8A58516F7@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 19:40:17 -0000 On 8 Apr 2020, at 19:56, otroan@employees.org wrote: > Right, so the broken operational practice of flash renumbering without > deprecating the old prefix approach to PD. > Let's make clear that's neither the recommended nor the typical way > ISPs operate their networks. Yes, please let this be made very clear! > In a typicaly deployment swapping CPEs or power cycling them does of > course not affect the delegated prefix. Based on a sample size on one ISP, this is not true in my experience. What I find is that any domestic power outage of about 15 minutes or more involves renumbering, even though my router is configured to send a hint for the prefix I want to re-use. Such events occur perhaps once in a year or two: frequently enough to be a nuisance, but not so frequently that I have a well-established SOP for dealing with them. /Niall From nobody Wed Apr 8 12:44:47 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288063A1687 for ; Wed, 8 Apr 2020 12:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cKbhAF14; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=izJ68HGK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hc3uHhkH2Fee for ; Wed, 8 Apr 2020 12:44:42 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A0F3A16D2 for ; Wed, 8 Apr 2020 12:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=440; q=dns/txt; s=iport; t=1586375076; x=1587584676; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wUM4pa4JGC3KK0+ngHDzBCTx/WYKPmuNkJIJM9fPti8=; b=cKbhAF14mF6EnXdUwaTcX/D/0m3xR0mOMnYBrS8qiIm5Q+F0tRNDDo0U HVrnjTswxBTkY1w/cQBOxTNvn/JLADlKBNQNZK7Ya3U0+HB5WqXQ4guaG h9gWQvH94KoyW6/cxjH95Pi2b6i2Cb1DI/iM96L7DL8F2dQowcSf5kqh8 w=; IronPort-PHdr: =?us-ascii?q?9a23=3AN5lOER8L/HTCaP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/YR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfJq3UeaNpJXh?= =?us-ascii?q?4Bh98Rmlk+B8qXIUb6N/XtKSc9GZcKWQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgCAClKI5e/5BdJa1mHgELHIFwC4F?= =?us-ascii?q?UUAWBRCAECyoKhBKDRQOKapp/gS6BJANUCgEBAQwBAS0CBAEBhEQCF4FwJDY?= =?us-ascii?q?HDgIDAQELAQEFAQEBAgEFBG2FVgELhXECAQMSEREMAQE3AQ8CAQgaAiYCAgI?= =?us-ascii?q?wFRACBA4NGoVQAy4BpgECgTmIYnWBMoJ/AQEFhVAYgg0JgQ4qjDMaggCBVIJ?= =?us-ascii?q?NPoRQgxAygiyRDaAnCoI9l1KCPQGZSosHPYN4nCsCBAIEBQIOAQEFgVkDL4F?= =?us-ascii?q?XcBWDJFAYDZEig3OKVXSBKY0ZAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.72,359,1580774400"; d="scan'208";a="460488516" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2020 19:44:35 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 038JiZFu024746 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Apr 2020 19:44:35 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 14:44:34 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 15:44:34 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Apr 2020 14:44:33 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bK65CXngtMVzbu6Ja5ItkXmkjXNZV4koY17lYV945q0n77C0FFyLPxNbgboHBYTMVorRJiAnr4UaGFfqQlX2142g9BcbsEFROVJreMwNXSdashTveTQvVYIRtwY6Y4bLzkhhvPa+zNgw8h8IvuAH8NWVmYQV3CmeJ9H1ImbsP87Q2+Ib4wWPvMhwJN8bIEgyNlf7hbavvYbA6AICOagLni4wVryA99ltDkS2f7JNikiDFEYDlNPWJKzAMfOI16U5hinWUBrURbl6sxfyfKpOgyrjusGs8TYPsBlZDLgYRzM/7laWADyBKS8Sb1JPBOSiI9mzHQWaVMbDCizYOoQXZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wUM4pa4JGC3KK0+ngHDzBCTx/WYKPmuNkJIJM9fPti8=; b=g2niIi+lIZYW4rEEBxoPvxEpBOYyoMXY7E/thcwntinMQEkDyvwCfOFF45+lLPvvpWYudmieCnYqXsDKDtKY1oYAa8GAQmbly62S35Qm598pP45kbHYmOARMlNuQT5AEiQrl0m6eGcKp0zvKdxjNgksQfFUBfcjja5Z+nCpJGk+Z8oqzMCVM/oCn4IeTDSVcqv2hTiynL3lT4BYk7cTUEdT1ytmxdEcGK9Y9rKLrXQzQyPW48c5SIOpX3cwrObT9OgcgJ26RR9yGxW9InL3sJXUQSiszSlN4iAJXvEpg7y6wx7MypmENsoKbABg4RaXy3Bpw8EVm2q1TOoRnvBr6Eg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wUM4pa4JGC3KK0+ngHDzBCTx/WYKPmuNkJIJM9fPti8=; b=izJ68HGKhJa3AiZCjimtV2zvFOtjqWm9k9OPXXnnpwH2NfTCLNaKl2tblyLQzRAq6jp52YDBvICJ7VYS7w7jpT5TjESmRH0yeQfplk+vmpXZJJ0+gNTLJP2Nc2pK0PjlN04c9MZa0t1YvMKjxdlFQ+CgTMLLfp4mbpO9YX3dmdk= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2771.namprd11.prod.outlook.com (2603:10b6:406:a9::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Wed, 8 Apr 2020 19:44:32 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Wed, 8 Apr 2020 19:44:32 +0000 From: "Bernie Volz (volz)" To: "otroan@employees.org" CC: Fernando Gont , IPv6 Operations Thread-Topic: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes Thread-Index: AQHWDZ1XwKMiAc+bXU6k0lDVbIJuY6hvTjSggAAGxICAAC+AgIAABxUAgAAC2oCAAAGPgIAAA38AgAACLYCAAAPhAIAAAplwgAAA2PCAAADzMA== Date: Wed, 8 Apr 2020 19:44:32 +0000 Message-ID: References: <4E01DB76-DBF4-4B6D-B054-2A011E0AC3A6@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 582ccc1e-af06-4cce-0748-08d7dbf54278 x-ms-traffictypediagnostic: BN7PR11MB2771: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(39860400002)(396003)(136003)(366004)(346002)(9686003)(26005)(5660300002)(81156014)(8676002)(8936002)(4744005)(6916009)(86362001)(71200400001)(76116006)(52536014)(66946007)(64756008)(66446008)(66476007)(7696005)(6506007)(33656002)(55016002)(186003)(2906002)(316002)(81166007)(54906003)(66556008)(478600001)(4326008)(2940100002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RbJBG+ROxmfPrM9uqhNw+S3d+tAXPdYNJiERYADq0AapjXn3uNuz9Wo/GRD9Jf3aytPocIjdSgXZlbG43s6Yo3IZ1aOgijjyifUxCTYz6hv6QeaaJupH/+uHrAStbvtYTbqI/8PccdDVhc1egDBkx1dpLOmO3EyDEIri88b8/5Pb+/JCBPjenD/9+5MgqQeP+HhDVz+Gi10Egn+j/vRuoKbATNmIW6dpRwQQwch10FbaEyyizR+0g6Ez4c924tJ3nUvJnCR/vx3Ps0QdQIauvX5UijTFULcikq6U1kWBxTuuuH6WhuOPVsCCFTXl9oCde8J97ujyBelV39lRM1QhsKhbGAlgAjGBnIc9gOLj8CSZ5IrvRNdNdenrN4e6MdzqGj8WCkMjtGnxutZ9n7LUIyWKQCLs/j6nrcZhVtb0N7huKeIGHpn/msLgrBwGay8o x-ms-exchange-antispam-messagedata: yZI6A4WF2G0lYN3VQ4Fn15FWeUeWpN+27IR3FoMGzv9kUAYFu36GBlcXeuqcWFE7/iz8d4vK+Wxdl28kK1pmNePLka7wYj67pYwUBzMH09HJL2udZDgQZLO1FCH+eGE5R7ssq94SXYnId6SIMHkeRA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 582ccc1e-af06-4cce-0748-08d7dbf54278 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 19:44:32.3438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mkEXY7u7cg0DvdC2QQZKA5MulZjD2Zll+8L6ePWq0WdQe9lDXguXGs8mAp0Uzbus X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2771 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 19:44:46 -0000 SGk6DQoNCk9sZSwgcGVyaGFwcyBpZiB0aGVyZSB3YXMgYSBjb25jcmV0ZSBwcm9wb3NhbCBmb3Ig YW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2gsIHdlIHdvdWxkIGdvIHRoZXJlPyBTbyBtYXliZSB0aGlz IGRlYmF0ZSBuZWVkcyB0byBiZSBwdXQgb24gaG9sZCBhIGJpdCB0byBhbGxvdyBhbHRlcm5hdGl2 ZSBhcHByb2FjaGVzIHRvIGNvbWUgYWJvdXQuIFRob3VnaCBhcyBzdGF0ZWQgZWFybGllciwgc29t ZSBvZiB0aGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBmb3IgYSB3aGlsZSBhbmQgSSBkb24ndCB0aGlu ayB0aGVyZSBhcmUgYW55IHlldD8NCg0KLSBCZXJuaWUNCg== From nobody Wed Apr 8 13:25:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EF23A167A for ; Wed, 8 Apr 2020 13:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRUEX-xw4dmj for ; Wed, 8 Apr 2020 13:25:47 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03613A1677 for ; Wed, 8 Apr 2020 13:25:46 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 759E780525; Wed, 8 Apr 2020 22:25:43 +0200 (CEST) To: Niall O'Reilly , IPv6 Operations References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> <5AACFB5F-D67D-4779-B5EB-E6D8A58516F7@fugue.com> <1E67F361-9E86-4751-AD77-FDA6777C5571@ucd.ie> From: Fernando Gont Message-ID: <902f5913-2b74-e18d-0667-9868a2c48979@si6networks.com> Date: Wed, 8 Apr 2020 17:25:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <1E67F361-9E86-4751-AD77-FDA6777C5571@ucd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 20:25:49 -0000 Hello, Niall, Thanks a lot for your feedback! In-line... On 8/4/20 16:40, Niall O'Reilly wrote: > On 8 Apr 2020, at 19:56, otroan@employees.org wrote: [...] > >> In a typicaly deployment swapping CPEs or power cycling them does of >> course not affect the delegated prefix. > > Based on a sample size on one ISP, this is not true in my experience. > > What I find is that any domestic power outage of about 15 minutes > or more involves renumbering, even though my router is configured > to send a hint for the prefix I want to re-use. Indeed, that's in-line with the data that we have. > Such events occur perhaps once in a year or two: frequently enough > to be a nuisance, but not so frequently that I have a > well-established SOP for dealing with them. In many parts this may happen easily once a week. So you might imagine the hassle this represents. 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 Apr 8 13:47:08 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518393A1784 for ; Wed, 8 Apr 2020 13:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKdCD-aGsz2j for ; Wed, 8 Apr 2020 13:47:05 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D74F3A1783 for ; Wed, 8 Apr 2020 13:47:05 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79d:53aa:d30:7cd9:be0:e3ee:7b15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 2C51C4E11B6D; Wed, 8 Apr 2020 20:47:04 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 19466318EEB0; Wed, 8 Apr 2020 22:46:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: <91E3C450-57C9-4809-B4F3-B6210F27E09C@fugue.com> Date: Wed, 8 Apr 2020 22:46:55 +0200 Cc: Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <91E3C450-57C9-4809-B4F3-B6210F27E09C@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 20:47:07 -0000 >> Sorry, I don't see the gap. >> All deployments I am aware of use the remote-id / option-82 = equivalent option to identify subscribers. >> Most operators are a lot more clueful about this than us here. >>=20 >> Think of PD as a contract. The ISP promises to lease the prefix to = the subscriber for the time stated. >> The ISP can still do flash renumbering (although that's likely to = induce a customer call) in two ways. >> One, just ignore it's earlier promise and give the subscriber a new = prefix (which introduces all the problems Fernado wants to use prefix = lifetimes to solve), or it can include the old prefix with lifetimes 0 = (violating it's earlier promise, but at least being explicit) and = advertise a new prefix. >=20 > I=E2=80=99m trying to figure out why this is such an utterly = unsatisfying response. Yes, I get that in the ideal case, which is what = you are describing here, there is no problem. But you are missing _all_ = of the edge cases. And you=E2=80=99re assuming that things on a home = network are a lot cleaner than I think is safe to assume. >=20 > So yes, in the case you describe, where everything is done correctly, = there is no problem. I would not expect to see the persistent prefix = problem routinely. But I think it=E2=80=99s worth designing for=E2=80=94t= here are a lot of reasons why renumbering might happen in a way that is = not as clean as you=E2=80=99re saying it should be, and we ought to = handle it gracefully when it happens. s/ideal/typical/ This small problem has a couple of simple solutions: - change to an ISP that operate better - the CPE sends back an ICMP in these cases, it's just for the host to = act upon it You might find the response unsatisfying, because I think we need to = focus on the wider problem. A solution to that would regardless solve = the case above. A host that has multiple addresses with different reachability is = typical in IPv6. Every host is essentially multihomed. With ephemeral = addresses. The case you describe above is not any different from that. The = host-stack/application needs to react to the connection not making = progress and try a different SA/DA pair. Similarly on initial connection. You don't solve that problem by tweaking prefix lifetimes. Cheers, Ole From nobody Wed Apr 8 14:04:17 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE713A17B5 for ; Wed, 8 Apr 2020 14:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G23M_FhckbQI for ; Wed, 8 Apr 2020 14:04:11 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2AAA3A17DC for ; Wed, 8 Apr 2020 14:04:11 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id 103so1902848otv.0 for ; Wed, 08 Apr 2020 14:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZekLDtxqJAbEi1ORY7m0pezjmAF+VCJijGuMk5nyksg=; b=vNa6jpg8ldztT3ap+tdV8xoY9wvq143HZGZWvOWKEPk8eh0G6BHlwWaaB0sOeooMEw wXTTwBDluUinRaTsGDOTJYp9Aryd//xjZkoMUJF8fMH2Y8TPyLN5wkI+A7Vs/73MP60Y hlvLD+70tUyyMq1pK39sUpKu/rIMUZOYwLpwyVhwYOLtMH+/643HmVXldsEnJaeOGdnl Dr9uStDqBj+c/U7pB1g42h6p16uRgno/vMRSsbRh9NZM4e7Je5bXT2Xx/Xh30w5X8E/p jWoFsZbVBLZjNNndiDQbKcKUuHqLZwFC3J1CnW0Bg8GZUdsbhsAiubRl2lkzu5OcpHEt NSfQ== 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=ZekLDtxqJAbEi1ORY7m0pezjmAF+VCJijGuMk5nyksg=; b=Rlp83XJGIFZgY6A8zezLk61TUlgLAl14GljUQ5OmInbqGYjN+/j+pX8Z6g7bISfqpq ewOu5cjBZqHsB3KPRj8kmVBxTLfYLpU8iTSR37z35GLWxZCL4BTtxX43w7Go0lHL6+mp 9fzOExJLHRbdgizTRuFCAHVY/qAlJa7zMoOSov2F3DMiTXegHX5nHb5HlsSlqclFoY5i bMYUx0vjuQS8TRxACDcdH4sfw8bTuSqzmDhGUdcRIU9cd3HRdk2vpoPj9UAHuMe/zuio JEJubRBjZup8fxQjcmmmzHcxHTvF9qC2CfhCl5bqqoKLCZLtsRhif0qpOGQYwOIpgc9U 7CVw== X-Gm-Message-State: AGi0PuYaImxv/vY/QjzwsdM+XbReKdCjM6bC9z/JEzDpxhUNajcMuVQo sP5UbPRtZlPJa4IRwHCU2mPPvFsNJfnZYI0+Kgzs7w== X-Google-Smtp-Source: APiQypKNV7NjmkotYQ9TYAixcRqZa0u/YaZE1m4aphs2k8XJJSi9Hw7HdDEwXu7Bh4pvENert1Ao3VSlAjC1N9bco64= X-Received: by 2002:a9d:1402:: with SMTP id h2mr7385438oth.74.1586379851022; Wed, 08 Apr 2020 14:04:11 -0700 (PDT) MIME-Version: 1.0 References: <522CDB81-37AE-4D27-B6F3-B3A49B53054D@employees.org> <451C08C9-376F-4275-B8CF-2FD9C194A606@fugue.com> In-Reply-To: <451C08C9-376F-4275-B8CF-2FD9C194A606@fugue.com> From: Mark Smith Date: Thu, 9 Apr 2020 07:04:00 +1000 Message-ID: To: Ted Lemon Cc: Ole Troan , Fernando Gont , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters Content-Type: multipart/alternative; boundary="0000000000007fc5ac05a2cdd767" Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 21:04:15 -0000 --0000000000007fc5ac05a2cdd767 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 8 Apr 2020, 10:03 Ted Lemon, wrote: > It would probably work better to factor preferred lifetimes into source > address selection. iOS, if two source addresses are otherwise equivalent, > pick the one that=E2=80=99s valid longer. > That would only work if all addresses started out with the same initial valid lifetimes, and hosts learned/configured all addresses at the same moment, so that the current valid lifetime is comparable across the addresses. That may not be the case since initial lifetimes are a network operator settable parameter rather than an IETF constant, and different routers on a link can come and go and advertise different prefixes with different initial valid lifetimes. Regards, Mark. > This does argue for capping valid lifetimes in RAs. > > We could also sort by time of most recent RA. > > > On Apr 7, 2020, at 19:47, Ole Troan wrote: > > > > =EF=BB=BFFernando, > > > >>> On 8 Apr 2020, at 01:29, Fernando Gont wrote: > >>> > >>> =EF=BB=BFOn 7/4/20 11:36, otroan@employees.org wrote: > >>> Ted, > >>>>> I think this idea of trying to make address lifetimes act as dead > timers for reachability severely broken. > >>>> > >>>> I think that in principle this is true, but I=E2=80=99m not sure tha= t it > follows in practice. What should we be doing instead? Or was this just = a > miscommunication, per Lorenzo=E2=80=99s clarifying message? > >>>> > >>>> My experience with this tends to make me want to agree with Lorenzo. > The longer a PIO prefix lifetime is, the longer things are broken when th= e > router stops advertising the prefix without deprecating it. OTOH, it=E2= =80=99s > _always_ going to be too long, so as you say, we really want a better way > to detect that we have a problem. Right now if one device remembers a > stale on-link prefix that another device has not seen, the first device m= ay > choose that stale prefix during source address selection, and of course > since the second device doesn=E2=80=99t see it as on-link, this will fail= . > >>>> > >>>> How do we quickly detect this failure? > >>> Exactly. It doesn't much matter if the prefix lifetime is 100 years o= r > two hours. The user isn't going to sit around for that time anyway. > >> > >> Reducing the preferred lifetime essentially improves the time it takes > to deprecate and subsequently eliminate addresses corresponding to a rout= er > that simply disappears. > >> > >> It's not perfect, but it way better than what we currently have. (but > see below). > > > > It=E2=80=99s a fool=E2=80=99s errand to think you will fix this with sh= ort lifetimes. > > Either they are so short that they expire during a link flap or they > will regardless be so long that it=E2=80=99s beyond an acceptable wait ti= me for a > user. > > > > > >>> slaac-renum solves a small corner case of this problem space. > >> > >> slaac-renum mitigates the case described above, *and* also solves in a > very efficient and timely manner handle the case where e.g. a CE Router > crashes and reboots. I'm not sure what's your definition of corner-case -= - > but this is a very common scenario. And, as it should be clear from this > discussion, there are multiple reasons for which such scenarios could tak= e > place (CPE crashes and reboots, CPE announces PIOs with a lifetime that > spans past the DHCPv6-PD lease, etc.) > > > > Not sure what you mean by the case of a cpe crashing and rebooting and > why that should matter. > > > > And may I remind you that ipv6 hosts are used in a diverse set of > networks. > > > > Cheers > > Ole > > > >> > >> 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 > --0000000000007fc5ac05a2cdd767 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, 8 Apr 2020, 10:03 Ted Lemon, <mellon@fugue.com> wrote:
It would probably work better to factor preferred lifetimes into source= address selection. iOS, if two source addresses are otherwise equivalent, = pick the one that=E2=80=99s valid longer.

That would only work if all addre= sses started out with the same initial valid lifetimes, and hosts learned/c= onfigured all addresses at the same moment, so that the current valid lifet= ime is comparable across the addresses.

That may not be the case since initial lifetimes are a netw= ork operator settable parameter rather than an IETF constant, and different= routers on a link can come and go and advertise different prefixes with di= fferent initial valid lifetimes.

Regards,
Mark.

=


This does argue for capping valid lifetimes in RAs.

We could also sort by time of most recent RA.

> On Apr 7, 2020, at 19:47, Ole Troan <otroan@employees.org> wrote:
>
> =EF=BB=BFFernando,
>
>>> On 8 Apr 2020, at 01:29, Fernando Gont <fgont@si6networks.com> wrote:
>>>
>>> =EF=BB=BFOn 7/4/20 11:36, o= troan@employees.org wrote:
>>> Ted,
>>>>> I think this idea of trying to make address lifetimes = act as dead timers for reachability severely broken.
>>>>
>>>> I think that in principle this is true, but I=E2=80=99m no= t sure that it follows in practice.=C2=A0 What should we be doing instead?= =C2=A0 Or was this just a miscommunication, per Lorenzo=E2=80=99s clarifyin= g message?
>>>>
>>>> My experience with this tends to make me want to agree wit= h Lorenzo.=C2=A0 The longer a PIO prefix lifetime is, the longer things are= broken when the router stops advertising the prefix without deprecating it= .=C2=A0 OTOH, it=E2=80=99s _always_ going to be too long, so as you say, we= really want a better way to detect that we have a problem.=C2=A0 Right now= if one device remembers a stale on-link prefix that another device has not= seen, the first device may choose that stale prefix during source address = selection, and of course since the second device doesn=E2=80=99t see it as = on-link, this will fail.
>>>>
>>>> How do we quickly detect this failure?
>>> Exactly. It doesn't much matter if the prefix lifetime is = 100 years or two hours. The user isn't going to sit around for that tim= e anyway.
>>
>> Reducing the preferred lifetime essentially improves the time it t= akes to deprecate and subsequently eliminate addresses corresponding to a r= outer that simply disappears.
>>
>> It's not perfect, but it way better than what we currently hav= e. (but see below).
>
> It=E2=80=99s a fool=E2=80=99s errand to think you will fix this with s= hort lifetimes.
> Either they are so short that they expire during a link flap or they w= ill regardless be so long that it=E2=80=99s beyond an acceptable wait time = for a user.
>
>
>>> slaac-renum solves a small corner case of this problem space.<= br> >>
>> slaac-renum mitigates the case described above, *and* also solves = in a very efficient and timely manner handle the case where e.g. a CE Route= r crashes and reboots. I'm not sure what's your definition of corne= r-case -- but this is a very common scenario. And, as it should be clear fr= om this discussion, there are multiple reasons for which such scenarios cou= ld take place (CPE crashes and reboots, CPE announces PIOs with a lifetime = that spans past the DHCPv6-PD lease, etc.)
>
> Not sure what you mean by the case of a cpe crashing and rebooting and= why that should matter.
>
> And may I remind you that ipv6 hosts are used in a diverse set of netw= orks.
>
> Cheers
> Ole
>
>>
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com<= /a>
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492=
>>
>>
>>
>>

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops
--0000000000007fc5ac05a2cdd767-- From nobody Wed Apr 8 14:19:40 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4123A1773 for ; Wed, 8 Apr 2020 14:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAA7qHZ8VjjU for ; Wed, 8 Apr 2020 14:19:37 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C333A1769 for ; Wed, 8 Apr 2020 14:19:37 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 C22378081B; Wed, 8 Apr 2020 23:19:33 +0200 (CEST) To: "Bernie Volz (volz)" , "otroan@employees.org" Cc: IPv6 Operations , Erik Kline References: <4E01DB76-DBF4-4B6D-B054-2A011E0AC3A6@fugue.com> From: Fernando Gont Message-ID: Date: Wed, 8 Apr 2020 18:19:18 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] slaac-renum: Protocol-based improvements (Re: cpe-slaac-renum: Proposed text for prefix lifetimes) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 21:19:39 -0000 Hi, Bernie, On 8/4/20 16:44, Bernie Volz (volz) wrote: > > Ole, perhaps if there was a concrete proposal for an alternative approach, we would go there? So maybe this debate needs to be put on hold a bit to allow alternative approaches to come about. Though as stated earlier, some of this has been discussed for a while and I don't think there are any yet? We have discussed this for over a year now. Ole has repeatedly argued that this is not a problem, or that this is not a problem worth solving, because the networks that face these problems suffer from the incompetence/lack of knowledge of their admins/operators (even after multiple-statements from operators on why these scenarios take place). He deems these occurrences as rare, while concrete data and anecdotal evidence suggests 40% of deployments doing dynamic addresses. In such scenarios, he argues that the user should switch ISPs, when in so many different places I know of, there is no other ISP to switch to. Now, the topic has been debated for over a year now. Nobody prevented anybody to come up with something better.. and as you correctly note, nobody did. On our side, we kept working on this. A few folks (Jen and Philip to name a few) found flaws in our early proposal, and suggested improvements, which we did our best to incorporate. We also discussed this with as many operators (this was discussed, IIRC, in RIPE, UKNOF, LACNOG..) and developers as possible, and received very positive feedback. And we also took the time to produce implementations of some of the improvements we propose (please see: https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06#section-6), or discuss this with developers that might want to improve SLAAC. Maybe in order to honor the motto of "we reject kings", it would be time for the working group to be polled for adoption of this document. Certainly not to rubber-stamp it, but to continue polishing and improving it where/as appropriate. 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 Apr 8 15:04:31 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8C73A186D for ; Wed, 8 Apr 2020 15:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 IFzpLMuWcO0o for ; Wed, 8 Apr 2020 15:04:29 -0700 (PDT) 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 10BF23A186B for ; Wed, 8 Apr 2020 15:04:28 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id y3so1994523qky.8 for ; Wed, 08 Apr 2020 15:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ubbDM6R5OaRt1NterLRS9QX9RrT/O5HlzKQ0iwuedpc=; b=t2OM3nJaSaC6WcgzT2L8WpXIkRYbR1wpnCyFHgUS2ZiiOVSGs4eXL1/WYG45xfniOp txA070g52tPQ79t467k/6WLAUubR2saet7/srRo2qUhbOgCR+KuZtsifzQ+AQ+OWj7hA HIELG5+QuzanGYCh+RY1WHCk7FciBixic+7OR5VKGsHRrEEppIIiUimCkyoFTmlUBT2d fidvw5vnPtS9tO3zo6EWE9KfjtjMD7KUkiVepMtKO/jJCQJeJ+tG51cQE4q0P/G3dZPs k2AnFVbuI0yRFCtEBfzGxpa4VEWlXbt/dOs4nsHzNyBret503iWNbQ9Vdrnw5mJOMUa9 fmJA== 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=ubbDM6R5OaRt1NterLRS9QX9RrT/O5HlzKQ0iwuedpc=; b=ZJE+MYPuvyokruUTjAaXjIbj/JMKVDtnlxRmAtfHQR3XCQjXGEKNhehSbcCxs1XfNk /5LrPKORI4REPAYzqqz6bFumqKazNrtot1ZmF2XIGiMkJ4Pxnay+5oKPFu5YyY/NT4j8 WFU4k9hG4V/IBpofATiM1SiTCqR82MBR4aA/O44I4xsCar+AW1AdOkhsEnZCwn3A5zBK zprExySaAA1bMsALvuE+ttgB8VyHknX9FPhO26ltIYME9wAKQO3bcXEDu3L9N6NIYnJM kR/v6HPWh/d2mX018NJiHGurGagu0Qi7X37AR6vjp1Me1fpLA9UapEsC815q1Nlfc6Gg pHpA== X-Gm-Message-State: AGi0PuYR+kjDAYnAGkJubbMXwa+yq5Mnsv6lKuATDkMzbBpSkzjv34e+ UV4L2O7l6Db+403A3SuM12zztA== X-Google-Smtp-Source: APiQypID7rY3iBusnDaYNyQkhhLZoulbxZBvvQEm5G10ugswLOJzAUgZQPDjCc7/o4ZRLL8//j8biA== X-Received: by 2002:a37:65c3:: with SMTP id z186mr8736019qkb.484.1586383467647; Wed, 08 Apr 2020 15:04:27 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id d141sm19737476qke.68.2020.04.08.15.04.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2020 15:04:27 -0700 (PDT) From: Ted Lemon Message-Id: <6F3DBB51-FD19-4E99-A3DD-2A409E3F61DF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AAD56A42-5307-46EB-B968-4026D0CCA2A0" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.6\)) Date: Wed, 8 Apr 2020 18:04:24 -0400 In-Reply-To: Cc: Ole Troan , Fernando Gont , "v6ops@ietf.org" , Lorenzo Colitti , Timothy Winters To: Mark Smith References: <522CDB81-37AE-4D27-B6F3-B3A49B53054D@employees.org> <451C08C9-376F-4275-B8CF-2FD9C194A606@fugue.com> X-Mailer: Apple Mail (2.3622.0.6) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 22:04:31 -0000 --Apple-Mail=_AAD56A42-5307-46EB-B968-4026D0CCA2A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 8, 2020, at 5:04 PM, Mark Smith wrote: > That would only work if all addresses started out with the same = initial valid lifetimes, and hosts learned/configured all addresses at = the same moment, so that the current valid lifetime is comparable across = the addresses. >=20 > That may not be the case since initial lifetimes are a network = operator settable parameter rather than an IETF constant, and different = routers on a link can come and go and advertise different prefixes with = different initial valid lifetimes. I understand the math, but if the CPE is capping prefix lifetimes, and = ISPs are sending long-lived prefixes, then this won=E2=80=99t actually = be a problem in practice. To address Fernando=E2=80=99s point about flapping, one way to deal with = this is to assume that routers will advertise at least every ten = minutes, and only when the difference in preferred lifetimes is greater = than ten minutes do we prefer the longer lifetime. --Apple-Mail=_AAD56A42-5307-46EB-B968-4026D0CCA2A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Apr 8, 2020, at 5:04 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
That = would only work if all addresses started out with the same initial valid = lifetimes, and hosts learned/configured all addresses at the same = moment, so that the current valid lifetime is comparable across the = addresses.

That = may not be the case since initial lifetimes are a network operator = settable parameter rather than an IETF constant, and different routers = on a link can come and go and advertise different prefixes with = different initial valid lifetimes.

I understand the math, but if the CPE is = capping prefix lifetimes, and ISPs are sending long-lived prefixes, then = this won=E2=80=99t actually be a problem in practice.

To address Fernando=E2=80=99= s point about flapping, one way to deal with this is to assume that = routers will advertise at least every ten minutes, and only when the = difference in preferred lifetimes is greater than ten minutes do we = prefer the longer lifetime.

= --Apple-Mail=_AAD56A42-5307-46EB-B968-4026D0CCA2A0-- From nobody Wed Apr 8 15:08:49 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1623A1879 for ; Wed, 8 Apr 2020 15:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGdPxTbrUZQP for ; Wed, 8 Apr 2020 15:08:46 -0700 (PDT) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB04E3A1876 for ; Wed, 8 Apr 2020 15:08:45 -0700 (PDT) Received: by mail-qv1-xf2e.google.com with SMTP id bu9so4520211qvb.13 for ; Wed, 08 Apr 2020 15:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EMlcyhPMOwKv/84XdNYvaezGZTrtnrmhwRU70llnoyI=; b=GGdb+NsnRg5X8gsZEfLTP3mx9Dgk8oNU/CKLZaORQnIyJ6WqZlRG7iUUZmjRbHxi9t RhQYKo9zQhGGiHx09ni6nOk2hkY4aXKywsqV0tPOxzHZMHaJhvqiIDK94EArlUAK1947 iAEr/6RNd0V4XcBm/5vt9S6sBEpP33QEgCkaVbyAqs/XqKxvKCYMvec/IaCIeSXkNvJf 4YOStBVDVu2qnPCLtoKP61O4yt0g++jJVGEhUbmhGSPp1hM4ehdHRo8oYeJxbmTAxOFc HA+U3Lp3hSDExoHUayqlOstTIqzdxYRhLZeiyojhJBrkssaN0hS0McadkcfoJWJ3DCqT cUFA== 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=EMlcyhPMOwKv/84XdNYvaezGZTrtnrmhwRU70llnoyI=; b=cKmY1OhUqtEM30JmSgMQSNu4hj5s13Ml2EHu+SiGhqn+Cg3NHIxXWy9EU5OWRr3aDD 3zTAWJ3Amu6RaCPPv4fDwumHzOWpnkDbvM8PxJ1rYTu8YmeosTMmTNgl+YgXe6m3KG+p 9VUk08hz790+8C9GNkvJmhTLwZ/XVNqkPrqL16nSPWOilkkdvuEhFSJzYU+2B4ii4U/I kYKWQ9sAJdeHRa4J9cw+X3/rAGoK/HvelLpjKpkiMfkDmkPQj2iRs3e6d3r3P73CAlhp WG4wihOeVNYePQZv/Zvdwnd2VK8VNeu05Rxeb5P+AgbXQN6+9YNO4krUQvToAICD8+bf 0D/A== X-Gm-Message-State: AGi0PuYIAo5xnWOznHr+GbdCGHVjU3ht5bE5WMx8pwLxO+Z59wwhb7/d qy/kZnez80j3UizZlfz/tRXkmrA6Rys= X-Google-Smtp-Source: APiQypLX24vZVwuXUuWguyu4ZX1bwMDXLOuokgR0SVZzMWXn8/8qXO1ZXOOmaF2iuHqDKbBBxvyoAw== X-Received: by 2002:ad4:44b4:: with SMTP id n20mr5982941qvt.139.1586383724710; Wed, 08 Apr 2020 15:08:44 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id x124sm20430752qkc.70.2020.04.08.15.08.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2020 15:08:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.6\)) From: Ted Lemon In-Reply-To: Date: Wed, 8 Apr 2020 18:08:42 -0400 Cc: Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <91E3C450-57C9-4809-B4F3-B6210F27E09C@fugue.com> To: otroan@employees.org X-Mailer: Apple Mail (2.3622.0.6) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 22:08:47 -0000 On Apr 8, 2020, at 4:46 PM, otroan@employees.org wrote: > s/ideal/typical/ NO. You don=E2=80=99t get to assert what is typical. Your assertion = doesn=E2=80=99t match what I am seeing from my own ISP, and apparently I = am not alone in that. And designing network protocols so that they only = work in typical circumstances is not good practice. >=20 > This small problem has a couple of simple solutions: > - change to an ISP that operate better I have one choice of ISP. > - the CPE sends back an ICMP in these cases, it's just for the host to = act upon it Can you explain this a bit more? > You might find the response unsatisfying, because I think we need to = focus on the wider problem. A solution to that would regardless solve = the case above. Porque no los dos? > A host that has multiple addresses with different reachability is = typical in IPv6. Every host is essentially multihomed. With ephemeral = addresses. > The case you describe above is not any different from that. The = host-stack/application needs to react to the connection not making = progress and try a different SA/DA pair. > Similarly on initial connection. >=20 > You don't solve that problem by tweaking prefix lifetimes. And I didn=E2=80=99t say you did. I said, I would like it if stale = prefixes that aren=E2=80=99t coming back would be gc=E2=80=99d more = rapidly than once every month. I agree that just gc-ing stale prefixes doesn=E2=80=99t solve the = problems you mention here. From nobody Wed Apr 8 16:21:44 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2343A19A9 for ; Wed, 8 Apr 2020 16:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhanumWu93wT for ; Wed, 8 Apr 2020 16:21:40 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19003A19A1 for ; Wed, 8 Apr 2020 16:21:40 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 B4D6780736; Thu, 9 Apr 2020 01:21:36 +0200 (CEST) To: Ted Lemon , otroan@employees.org Cc: IPv6 Operations References: <91E3C450-57C9-4809-B4F3-B6210F27E09C@fugue.com> From: Fernando Gont Message-ID: <4402fcaf-b6bd-937e-3184-4bd98749de7f@si6networks.com> Date: Wed, 8 Apr 2020 20:19:24 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 23:21:43 -0000 On 8/4/20 19:08, Ted Lemon wrote: > On Apr 8, 2020, at 4:46 PM, otroan@employees.org wrote: >> s/ideal/typical/ > > NO. You don’t get to assert what is typical. Your assertion doesn’t match what I am seeing from my own ISP, and apparently I am not alone in that. And designing network protocols so that they only work in typical circumstances is not good practice. >> >> This small problem has a couple of simple solutions: >> - change to an ISP that operate better > > I have one choice of ISP. > >> - the CPE sends back an ICMP in these cases, it's just for the host to act upon it > > Can you explain this a bit more? > >> You might find the response unsatisfying, because I think we need to focus on the wider problem. A solution to that would regardless solve the case above. > > Porque no los dos? > >> A host that has multiple addresses with different reachability is typical in IPv6. Every host is essentially multihomed. With ephemeral addresses. >> The case you describe above is not any different from that. The host-stack/application needs to react to the connection not making progress and try a different SA/DA pair. >> Similarly on initial connection. >> >> You don't solve that problem by tweaking prefix lifetimes. > > And I didn’t say you did. I said, I would like it if stale prefixes that aren’t coming back would be gc’d more rapidly than once every month. > > I agree that just gc-ing stale prefixes doesn’t solve the problems you mention here. It's explained here: https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06#appendix-B.1 And the idea is broken. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Apr 8 16:33:26 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639CD3A19E3 for ; Wed, 8 Apr 2020 16:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Zx1DKE5kM5H for ; Wed, 8 Apr 2020 16:33:22 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957153A19E2 for ; Wed, 8 Apr 2020 16:33:22 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id b10so1402404qtt.9 for ; Wed, 08 Apr 2020 16:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=rAdxfOUogp/MxktIcSrSg9DLLRhzanebGTgiknU1pjE=; b=YYXtPokyxqtMsSAvm6mKxlT6f38i6CQ/MSHw1F+xhRZO3bHRpXQmJaroJe251KLauZ eih3/rer0tiTwHBAdCfjELYaYBHCXNBK5YVgnOdURr/5htam79eipoHYT5K5kbTDnAyc yjbVZMC20C8YPhfyvD/uWX1/k8Sz6nIjNGHB1Z08zKkpIx4iwlcSLVRalD5XRoephPNV giBn0bKD3Ce82+uFXL23hdoMndd/Qguqrx9B4ImINAXSm7tPHmV/57wYXRxhMrmwmAX0 TQrjhnjF3tIBqo1Oy0daWZsEYfjKBISgaszQE7R87hCOIDouvjtwf0weZWWprLfrgQNi Cc/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=rAdxfOUogp/MxktIcSrSg9DLLRhzanebGTgiknU1pjE=; b=I94x7yZFlWH6htVSjMwUiMfYzHwOBfBR0W+DYPfNJHSMewA+EpC6oGBhWPcKLs8CWC FNmfHkZixsQ9QTATocheq/JOqAEZZVy5DE1fB6OW09zsE3Qj0e3QUNdUCoNbLgnX7Dmp 0O1C/9t3ZGO5GRBAxz3UXANK34TRQQK6O6OdkHCrhz+VzGvlEwm54acRbopkDyKKk849 xivqEohXYMT4wLNZp4LOEZgpCv2/LwN3vyA9u2mJ7GIzYknBji3xUU06nmjSVdAq4W1Y zQ1hSDQUQcW7JnxUWTa9UUiymf3QS3nt9cpRrF6lVUXZH7AZ4tIiaPsJYOR1YRUbYAJN su8A== X-Gm-Message-State: AGi0PubTMJwrL2NO8sN8jpiTcdWQXHIKxOd6DgQFzYF72Z6sOJ6IntyG 50XUkvqXgfpULWMKC52fsS5/umAaJcc= X-Google-Smtp-Source: APiQypJWyjkZtU+dHa8V78fWLLd8+hi1aRdtCIWjptlJnkmihDUo0PiOpOTijfM5vSycOuwRK+QQTQ== X-Received: by 2002:ac8:3003:: with SMTP id f3mr2025506qte.293.1586388799981; Wed, 08 Apr 2020 16:33:19 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:201b:83ea:1756:69e4? ([2601:18b:300:36ee:201b:83ea:1756:69e4]) by smtp.gmail.com with ESMTPSA id b10sm10645446qtj.30.2020.04.08.16.33.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Apr 2020 16:33:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 8 Apr 2020 19:33:18 -0400 Message-Id: <93F8AEB5-242A-4178-83E1-D5F16360AA87@fugue.com> References: <4402fcaf-b6bd-937e-3184-4bd98749de7f@si6networks.com> Cc: otroan@employees.org, IPv6 Operations In-Reply-To: <4402fcaf-b6bd-937e-3184-4bd98749de7f@si6networks.com> To: Fernando Gont X-Mailer: iPad Mail (17E255) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 23:33:24 -0000 I agree with your analysis about ICMPv6=E2=80=94thanks for that. I think th= at the source address selection solution can work, though=E2=80=94it just re= quires a slightly more clever algorithm than the one you proposed and then r= ejected. I described it in another message. One thing that could be done with source address selection is that if an add= ress fails the test I described (choose the loser only if its preferred life= time is ten minutes longer than the incumbent), you could send a router soli= cit for the router that advertised that prefix; if there=E2=80=99s no respon= se to the solicit, then deprecate the prefix, and when there are no more ref= erences to any address on the prefix, gc any remaining addresses on that pre= fix and the prefix itself. Sent from my iPad > On Apr 8, 2020, at 7:21 PM, Fernando Gont wrote: >=20 > =EF=BB=BFOn 8/4/20 19:08, Ted Lemon wrote: >>> On Apr 8, 2020, at 4:46 PM, otroan@employees.org wrote: >>> s/ideal/typical/ >> NO. You don=E2=80=99t get to assert what is typical. Your assertion does= n=E2=80=99t match what I am seeing from my own ISP, and apparently I am not a= lone in that. And designing network protocols so that they only work in typ= ical circumstances is not good practice. >>>=20 >>> This small problem has a couple of simple solutions: >>> - change to an ISP that operate better >> I have one choice of ISP. >>> - the CPE sends back an ICMP in these cases, it's just for the host to a= ct upon it >> Can you explain this a bit more? >>> You might find the response unsatisfying, because I think we need to foc= us on the wider problem. A solution to that would regardless solve the case a= bove. >> Porque no los dos? >>> A host that has multiple addresses with different reachability is typica= l in IPv6. Every host is essentially multihomed. With ephemeral addresses. >>> The case you describe above is not any different from that. The host-sta= ck/application needs to react to the connection not making progress and try a= different SA/DA pair. >>> Similarly on initial connection. >>>=20 >>> You don't solve that problem by tweaking prefix lifetimes. >> And I didn=E2=80=99t say you did. I said, I would like it if stale prefi= xes that aren=E2=80=99t coming back would be gc=E2=80=99d more rapidly than o= nce every month. >> I agree that just gc-ing stale prefixes doesn=E2=80=99t solve the problem= s you mention here. >=20 > It's explained here: https://tools.ietf.org/html/draft-gont-6man-slaac-ren= um-06#appendix-B.1 >=20 > And the idea is broken. >=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 From nobody Wed Apr 8 16:38:54 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7093A19FA for ; Wed, 8 Apr 2020 16:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 2GOoxX-nRwde for ; Wed, 8 Apr 2020 16:38:52 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id CE0603A19F6 for ; Wed, 8 Apr 2020 16:38:51 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 038NcnJJ699794 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Apr 2020 16:38:49 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 038NcnJJ699794 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586389129; bh=qoaP+kgFkym8/PvXCxppr6hFwKn67uGIrgP5oMqPMWg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=vddlJB7MlL7/v/ozEBp6op9kLeyzUQ4cWY63CkJv2CCogRkHjF5yUcRWPqs3J2g6w 6QIjpEupKZo41S5EMK6r6KHEko+dkvjs1TZjpAypHRoLwOnwRa+l2OLOx/3/KL4nPe vwrMik+Wms8ZftehNAprJ/LrxOU6GvF/ppWbyvgI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: Date: Wed, 8 Apr 2020 16:38:49 -0700 Cc: Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <5FF0E1F8-333E-4E8F-A2AD-95B05C7473BB@delong.com> References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Wed, 08 Apr 2020 16:38:49 -0700 (PDT) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 23:38:53 -0000 If you don=E2=80=99t cap the valid lifetime, you won=E2=80=99t solve the = battery life problem raised by Lorenzo, because RAs will be constantly = counting down. IMHO, it=E2=80=99s better to cap both lifetimes locally. As long as the = router remains up, it=E2=80=99s going to get refreshed by the fresh RA = anyway. I think that the lifetimes should be long enough that most CPE = outages would likely be addressed (e.g. 9000 seconds =3D 2.5 hours, or, = if you want to be more conservative, 86400 seconds =3D 1 full day). If your only CPE went down for a day and nobody fixed it, loss of = long-lived local flows is probably going to be the least of your = problems. These SHOULD be recommended values with a requirements for manufacturers = to pick sane defaults for their target audience. Administrators SHOULD = be able to configure different values according to their preferences. Owen > On Apr 8, 2020, at 07:57 , Bernie Volz (volz) = wrote: >=20 > A few comments: >=20 > 1. One reason to cap the lifetime(s) in the CPE for RAs is that while = the SP could adjust the lifetimes, that has a direct impact on the = amount of DHCPv6 traffic as reducing the preferred lifetime will cause = the renewals to occur more frequently. That is one reason why SPs do not = use short preferred lifetimes. (Some SPs have many millions of CPEs.) >=20 > 2. I do wonder whether leaving the valid lifetime alone is better than = playing with both lifetimes. For most applications that don't require = long lived addresses, it achieves the desired effect. For those that = want long lived addresses, it allows for that (if case of outages longer = than the capped valid lifetime) -- and if the application decides to try = for a new address, it will use one in a new prefix if one was = advertised. >=20 > - Bernie=20 >=20 > -----Original Message----- > From: v6ops On Behalf Of Fernando Gont > Sent: Wednesday, April 8, 2020 8:00 AM > To: IPv6 Operations > Subject: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes >=20 > Folks, >=20 > In this recent thread on cpe-slaac-renum, there was a proposal to add = text to the draft, and I promised I would start a new thread just in = case somebody missed the chance to review in the rather long thread. >=20 > This text is meant to reflect the comments from Philip, Lorenzo, and = others (please do let me know if I misunderstood what you mean). The = text is: >=20 > ---- cut here ---- > The Valid Lifetime and Preferred Lifetime of PIOs have direct impact = on two different aspects: >=20 > * The amount of time hosts may end up employing stale network = configuration information (see [draft-ietf-v6ops-slaac-renum]). >=20 > * The amount of time Customer Edge routers would need to persist = trying to deprecate stale network configuration information (to handle = cases where nodes miss Router Advertisements and thus still consider the = stale information as valid). >=20 > As a result, CPE Routers SHOULD override the default "Preferred = Lifetime" and "Valid Lifetime" values from [RFC4861], and employ shorter = values to mitigate the aforementioned effect, while complying with the = requirement from Section 2.1 of this document, and the recommendations = in RFC7772. This document RECOMMENDS that Customer Edge Router set the = Router Lifetime and PIO Preferred Lifetime to 2700 seconds (45 minutes) = and the PIO Valid Lifetime to 86400 seconds (1 day). >=20 > We note that a CPE Router need not employ the (possibly long) = DHCPv6-PD lease times in the Valid Lifetime and Preferred Lifetime of = PIOs sent in Router Advertisements messages to advertise sub-prefixes of = the leased prefix. Instead, CPE Routers SHOULD use shorter values for = the Valid Lifetime and Preferred Lifetime of PIOs, since subsequent = Router Advertisement messages will nevertheless refresh the associated = lifetimes, leading to the same effective lifetimes as specified by the = DHCPv6-lease time. > --- cut here ---- >=20 >=20 > The above change tackles to different issues: >=20 > * Saner lifetimes that at least allow for proper garbage collection in = a timelier manner. >=20 > * In the typical scenario (but depending on DHCPv6 server parameters), = the DHCPv6-PD leased will be longer than the PIO lifetimes advertised by = the CE Router, and the CE Router will renew the prefix lease well before = the PIO lifetimes need to be adjusted/reduced (to avoid having PIO = lifetimes that span past the dhcpv6-pd lease). The result is that, in = practice, the CE Routers would send RAs that always contain the same = lifetime values, thus avoiding the battery consumption problem mentioned = by Lorenzo. >=20 > Thoughts? >=20 > Thanks! >=20 > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Apr 8 16:47:39 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CD13A1A0D for ; Wed, 8 Apr 2020 16:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 VXfaZt4FqKmy for ; Wed, 8 Apr 2020 16:47:37 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 04F753A1A09 for ; Wed, 8 Apr 2020 16:47:36 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 038NlThJ702823 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Apr 2020 16:47:29 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 038NlThJ702823 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586389650; bh=NWCX/SQ/JbdtHLfOcxrVgIGnnwPSShFD2HpYQ0hFJ6g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=b5BDB6PVpB8UGL1LkK0gBPgmn1dHTCGJRXN5lSHX81whltz5TCNlIGDDB3yXiH57a i/CpJ7b75id/LyMYgxbVINDfClVs43ohKpcxxXglO+0yjeqVdJ4yUtf+DRVnQwfrF/ FT2BbJ0PYaxds1XEeAoXKxKUNa7+8RP0H3ODvBwI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: Date: Wed, 8 Apr 2020 16:47:29 -0700 Cc: "otroan@employees.org" , Ted Lemon , Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E01DB76-DBF4-4B6D-B054-2A011E0AC3A6@fugue.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Wed, 08 Apr 2020 16:47:30 -0700 (PDT) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2020 23:47:39 -0000 If you have added a second, how would the ISP know whether it=E2=80=99s = duplicate infrastructure for redundancy or phased swap (in which case = you still want to delegate the same prefix) vs. a second independent set = of networks (in which case a unique prefix would be necessary)? Owen > On Apr 8, 2020, at 12:32 , Bernie Volz (volz) = wrote: >=20 > And, I should have added ... how does the SP know that you replaced = your CPE instead of adding a second. >=20 > At least in some deployments (such as DOCSIS) there's nothing = necessarily that precludes you from having multiple CPEs behind a CM. >=20 > - Bernie >=20 > -----Original Message----- > From: v6ops On Behalf Of Bernie Volz (volz) > Sent: Wednesday, April 8, 2020 3:28 PM > To: otroan@employees.org; Ted Lemon > Cc: Fernando Gont ; IPv6 Operations = > Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix = lifetimes >=20 >> All deployments I am aware of use the remote-id / option-82 = equivalent option to identify subscribers >=20 > Yes, that identifies the subscriber. But that is not the same as = identifying the CPE. We do, after all, have a client identifier option = (1) which is based on the DUID. >=20 > - Bernie >=20 > -----Original Message----- > From: v6ops On Behalf Of otroan@employees.org > Sent: Wednesday, April 8, 2020 3:18 PM > To: Ted Lemon > Cc: Fernando Gont ; IPv6 Operations = > Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix = lifetimes >=20 >>>>>> power cycled. You probably don=E2=80=99t _want_ to use long TTLs = on domain names, if any are published=E2=80=94e.g., for mDNS we use a = TTL of 75 minutes, and do a refresh at 60 minutes; we do the same thing = for Service Registration Protocol (DNS updates for DNSSD), although = that=E2=80=99s not widely deployed at present. >>>>>>=20 >>>>>> So in this case, where your device may be power cycled and lose = its state, or where the end user may simply unplug one device and plug = in another, having a really long preferred lifetime makes zero sense. = Obviously, having a shorter lifetime does not solve the problem of = cleaning up stale prefixes fast enough to prevent routing problems, but = we still want those stale prefixes to be cleaned up. As you say, there = are two different issues here. Reasonably short address lifetimes = avoids keeping addresses around for a month when they are stale and = aren=E2=80=99t going to be explicitly deprecated. For source address = selection and route selection, this doesn=E2=80=99t help, but it=E2=80=99s= still worth doing. >>>>>>=20 >>>>>=20 >>>>> You seem to be implying something here. >>>>> Why does it matter if a CPE is unplugged or power cycled? (Well, = apart from the obvious of being unable to forward packets for the = duration). >>>>=20 >>>> It matters if the CPE doesn=E2=80=99t maintain state between power = cycles, and gets a different prefix when it comes back. And it matters = if the CPE is swapped out without a clean shutdown that would result in = the prefix being deprecated, and subsequently gets a different prefix = from the ISP. In both of these cases, we want the old prefix to go = away sooner than a month. This doesn=E2=80=99t absolve us of having to = do the work to make sure that things work while that prefix is still = present, but we should also be letting it die cleanly. >>>>=20 >>>> I suppose the counterargument would be that if it=E2=80=99s still = valid, we still want to use it for existing connections, but it seems = unlikely that this could work in either of the situations I=E2=80=99m = describing. >>>=20 >>> Right, so the broken operational practice of flash renumbering = without deprecating the old prefix approach to PD. >>> Let's make clear that's neither the recommended nor the typical way = ISPs operate their networks. >>>=20 >>> In a typicaly deployment swapping CPEs or power cycling them does of = course not affect the delegated prefix. >>=20 >> Is it true that this is flash renumbering? Where in the PD spec does = it say that the server has to give the same CP (customer premises) the = same prefix? How does it identify the CP if the CPE has changed? I = know that there are ways to do that, but there is no RFC I know of that = says how to do that, or that requires that this be done. >>=20 >> Does the PD spec say that the ISP has to give the CPE the same = prefix, assuming that it _can_ identify it? >>=20 >> As I said earlier, I think it=E2=80=99s the case that if a PD is = issued, the DHCP server has to honor it until it=E2=80=99s no longer = valid, but unless we require that it return the same prefix in this case = when the CPE device doesn=E2=80=99t explicitly ask for it, there is a = significant gap here. >=20 > Sorry, I don't see the gap. > All deployments I am aware of use the remote-id / option-82 equivalent = option to identify subscribers. > Most operators are a lot more clueful about this than us here. >=20 > Think of PD as a contract. The ISP promises to lease the prefix to the = subscriber for the time stated. > The ISP can still do flash renumbering (although that's likely to = induce a customer call) in two ways. > One, just ignore it's earlier promise and give the subscriber a new = prefix (which introduces all the problems Fernado wants to use prefix = lifetimes to solve), or it can include the old prefix with lifetimes 0 = (violating it's earlier promise, but at least being explicit) and = advertise a new prefix. >=20 > Cheers, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Apr 8 17:01:30 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0093A0B6D for ; Wed, 8 Apr 2020 17:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 sWkuZam7wb-T for ; Wed, 8 Apr 2020 17:01:27 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 09AB53A1A32 for ; Wed, 8 Apr 2020 17:01:25 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03901NVO707671 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Apr 2020 17:01:24 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03901NVO707671 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586390484; bh=a8linAyOMB2L4l+D1GIArWOozicaH6fALmr0RRavr9Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=gVFQoTEcMZTqj2ptWoJ4tkjhhGe5IVU7ywy74+d8cK4treOD9k7KUVqVvcbP9TRyK /j3rHPNc745RzcjMNdeYO08Pb/v1yuZlE6DC6Gsm0IZM4VizaMZ/VYIuR7IK3k13Lu ZUwg9lFX6t1nyAclGTIdmEx8f67+jBV3Ft6rwb0E= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: Date: Wed, 8 Apr 2020 17:01:22 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5079EE4E-D48F-4C8A-ABBC-FB71DDFFC003@delong.com> References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> To: Philip Homburg X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Wed, 08 Apr 2020 17:01:24 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 00:01:28 -0000 > On Apr 8, 2020, at 02:40 , Philip Homburg = wrote: >=20 >> By definition if it is spanning a DHCPv6-PD issued lifetime, it is = NOT a =3D >> static prefix. >>=20 >> What am I missing? >=20 > DHCPv6-PD is used as a mechanism to populate the FIB of the access = router. >=20 > Just like you can have static IPv4 addresses and still hand them out = using=20 > DHCPv4. Nope. They=E2=80=99re fixed dynamic addresses at that point, not static = addresses. Similarly, you can receive a fixed dynamic prefix via DHCP-PD, but = it=E2=80=99s still being issued to you dynamically and it won=E2=80=99t keep working if you = don=E2=80=99t renew the lease. Owen From nobody Wed Apr 8 17:07:31 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1A43A1A4D for ; Wed, 8 Apr 2020 17:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=A0pVY/yF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=O8Y0dRmX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-IgaZDFlwEm for ; Wed, 8 Apr 2020 17:07:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29CB3A1A49 for ; Wed, 8 Apr 2020 17:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9242; q=dns/txt; s=iport; t=1586390846; x=1587600446; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=11bHTFBI22arXXJRa1W9oCc+7iX8ZcJjghlfCX/GO7A=; b=A0pVY/yFcAPMFpRwws/6FLlGXrztnER1aGAEgSiPAQ59urc76ibqnVvV x48AGHNAP6KjTpWyOEYAWexw3xlHYZVcr3D2YYSjiQ4Z7eZZ/l34gIS3a G2kYZ+XZ5DslERdx3LSwT4TFdYHJBSVBx8J1Gjowg9NRGmVfg0HxnBtCR Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AAfy4FB89DNFsBP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/YR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfJq3UeaNpJXh?= =?us-ascii?q?4Bh98Rmlk+B8qXIUb6N/XtKSc9GZcKWQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAAAAZ45e/5xdJa1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBaAUBAQELAYFTUAVsWCAECyoKhBKDRQOKaoJfgQGXH4E?= =?us-ascii?q?uFIEQA1QKAQEBDAEBGAsKAgQBAYREAheBcCQ1CA4CAwEBCwEBBQEBAQIBBQR?= =?us-ascii?q?thVYMhXABAQEBAgEBARAREQwBASwLAQQHBAIBCBEEAQEBAgImAgICJQsVCAg?= =?us-ascii?q?CBA4FGQYDgwQBgksDDiABDqVnAoE5iGJ1gTKCfwEBBYEvAYEVgwUYgg0DBoE?= =?us-ascii?q?OKgGMMhqCAIERJxyCGDU+gmcBAQKBICoBgyoygiyNbx+Cf6AnCoI9lzUdgk6?= =?us-ascii?q?IOpEAiwc9oCMCBAIEBQIOAQEFgVMBN4FXcBU7KgGCPlAYDViQSgeDbIUUhUF?= =?us-ascii?q?0AgEBgSWNGQGBDwEB?= X-IronPort-AV: E=Sophos;i="5.72,360,1580774400"; d="scan'208";a="755016839" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Apr 2020 00:07:25 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 03907PnI029177 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Apr 2020 00:07:25 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 19:07:24 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 20:07:24 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Apr 2020 20:07:23 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cQ5TchFGZXn2PVjcYfo+AQcUXI7e5tQbSYsEyjAbKMmRNOgyGJuqjrPtx/zDfBLnkya0/upXErmYOIkNSx8NN/J93sZZ06HoFvh1ZcsRQnjQtiGxRrH8Q6/Ewpl5EV6FjZflePkqgBLbOySuaIHBf8QK3vtHyiet8En9kCVTRy8zIqzRpHqDHEYZcrMLAXo0g1Bgb2oCFMdla0Vw1xRfO/0bvQEXSv0heTRkVphpo1NDFh/UDJj38TuRn+oVy6wBz4/AOoLd9H2cU5jZFWhvR/2/+i5lOTUSqd8od5m6jinMAKTu5PmwRPLPJBRcLnOL69R5u7LVT6Ekuo0UcXnKvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=11bHTFBI22arXXJRa1W9oCc+7iX8ZcJjghlfCX/GO7A=; b=VbK45Zxcgo7QnIqYKUdjlyOhL1EaQqDTFHNW0m9s6VzVddqx2v5tcf79dPE6CiclJvq2oJRlpokNWaNcVfx0f0ypWHokT9cLGrpNVwnOHptstePFx3SW6cuBVnwCm8kVGyPO+nmdjXpZdWXqLM+6Iq7oXlDVvOu9B7ZWCqH1flvwPl5tNms2ySCLpJQ9aSxOSyDBPT5T9UNFQ9uPev845RdZt1bpoXZMWllqokjti+TA+qmIzAm4uyRK+roEV9g0st4vdimuAcxIq88CjrJt/JxE32qDwcuTWIL22SiYqrqeNTI4Fw1hgrY/c7NBjpnUxtQhSK5t6cRKTnzQUsX7jQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=11bHTFBI22arXXJRa1W9oCc+7iX8ZcJjghlfCX/GO7A=; b=O8Y0dRmXgBBIKoFD1rUFOfzDeEa7fJg+tHKw1nBVUF8hWxjUpPzL2Auc8UHCvAcduoY0S8mQYnYrsDc/kXnJjoXBfsU1MyvZQFwkqf1P4o2Xj62xYmfae045Io8i9PtINrU/Q6fgxuIP4oKgIbjUfuJgPbf3XoxcLCIaWwXIyMM= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2817.namprd11.prod.outlook.com (2603:10b6:406:ac::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Thu, 9 Apr 2020 00:07:23 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2878.018; Thu, 9 Apr 2020 00:07:23 +0000 From: "Bernie Volz (volz)" To: Owen DeLong CC: Fernando Gont , IPv6 Operations Thread-Topic: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes Thread-Index: AQHWDZ1XwKMiAc+bXU6k0lDVbIJuY6hvTjSggACURoD//8TrAA== Date: Thu, 9 Apr 2020 00:07:22 +0000 Message-ID: <37AB379F-E51F-43DA-B9CA-A05845460B77@cisco.com> References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> <5FF0E1F8-333E-4E8F-A2AD-95B05C7473BB@delong.com> In-Reply-To: <5FF0E1F8-333E-4E8F-A2AD-95B05C7473BB@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b9a4907a-64a8-400f-3fdc-08d7dc19fa87 x-ms-traffictypediagnostic: BN7PR11MB2817: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(396003)(136003)(376002)(366004)(39860400002)(6512007)(76116006)(6506007)(6916009)(33656002)(64756008)(66446008)(186003)(71200400001)(8676002)(26005)(478600001)(2616005)(5660300002)(66556008)(6486002)(4326008)(966005)(53546011)(66574012)(8936002)(91956017)(54906003)(66946007)(2906002)(66476007)(81156014)(81166007)(86362001)(316002)(36756003); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WPJFaVzkJ6QveJFFWiNZbCtCczB+Pt+didBmdMnm9NEAAdcsgc6jwAUQ9/UGZbOf2NYG5kI7FBq9Rj2qgJ56gcuFlWm8ev/4DrZURPg00r8/ydOeFvGtXPtN/G2PjeokhPvnS5+/gCQsfhkCkcYQ9py7R6OIwaMvlUKFh0sw0BRQfnpyPoE3w2sbFictjaBCep+Vw+G74BugsIWy7NU0c7ehnb/HKGFKxm0ZC4CZPSGuAwulDuy7CdgD7SNlptKoDgtboZokAYk9ynmTr6a042Mo8EFK2pj9v9giU48MqEXT0ZZGFawYsDgSPzsCl7NPmPkIsxWQ1xuFR7jPOBMGS2u89A7017M5zzle6mATOI/h1eVpwB75lC1JdqfeQkbIx4tdiedPtErfPEBqLh4xu8JxClp3pxNACkJeT875FRpVhXGYwqv3w+xjkWmMuHGf0s68XrVNUroStVQuFAGT1+JOVi0dCsWv7oqiKpI9tAIXIdLbJvLBGhwVZUdg0keYLlOH7QSTRK23K29VwJrc/Q== x-ms-exchange-antispam-messagedata: BAuS8ICNXC4uPp97MtHHFF1gbvt8SJ8QnLiOUs1fR3A539h5C5UNqEuDv8W1DSCYEMKSvkrpEzZ46HKJ0UI/ifZOckyTZorGwTjqfZ8NIUZ9RwFFAsibPCgV8NDF8Vkgx99vsHW9WjuBI9G7QvvvsQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5EDBF424810D6D4A832C5076CE52BF18@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b9a4907a-64a8-400f-3fdc-08d7dc19fa87 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 00:07:22.9876 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JasZf8BglRmkMY0HxUFUDcA5r/sWU3RjqMTo+n6mlOQ/fbIcvQjs1No5zdQQ1QwU X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2817 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 00:07:29 -0000 PiAgICBJZiB5b3UgZG9u4oCZdCBjYXAgdGhlIHZhbGlkIGxpZmV0aW1lLCB5b3Ugd29u4oCZdCBz b2x2ZSB0aGUgYmF0dGVyeSBsaWZlIHByb2JsZW0gcmFpc2VkIGJ5IExvcmVuem8sIGJlY2F1c2Ug UkFzIHdpbGwgYmUgY29uc3RhbnRseSBjb3VudGluZyBkb3duLg0KDQpOb3Qgc3VyZSBJIHVuZGVy c3RhbmQgdGhpcy4gWWVzLCB0aGUgdmFsaWQgbGlmZXRpbWUgaW4gdGhlIFJBIHdvdWxkIGJlIGNo YW5naW5nLCBidXQgaG93IGRvZXMgdGhhdCBtYXR0ZXIgaWYgdGhlIFJBIGNvbWVzIGFueXdheT8g RWl0aGVyIHlvdSBzbGVlcCBpZ25vcmluZyBSQXMgb3IgeW91IGFyZSB1cCBhbmQgcHJvY2Vzc2lu ZyB0aGVtLiBBbHNvLCBpZiB5b3UgY2FwIHRoZSB2YWxpZCBsaWZldGltZSBhdCAyLjUgaG91cnMs IGFuIFJBIGF0IHRpbWUgWCBoYXMgYSBsaWZldGltZSB3aGljaCBlbmRzIGEgWCArIDIuNWgsIGFu ZCBpZiBhbm90aGVyIFJBIGNvbWVzIDEgbWludXRlIGxhdGVyIHdpdGggYSBjYXBwZWQgdmFsaWQg bGlmZXRpbWUsIGl0IHdpbGwgbm93IGVuZHMgYXQgWCArIDFtICsgMi41aC4gSG93IGRvZXMgdGhp cyBzYXZlIGJhdHRlcnkgbGlmZSBhcyBpdCBzdGlsbCBpcyBhIHRpbWUgY2hhbmdlPw0KDQpUaGUg b25seSB3YXkgeW91IHdvdWxkIGF2b2lkIGEgY2hhbmdlIGluIHRpbWUgaXMgaWYgdGhlIENQRSBh bHNvIG9ubHkgdXBkYXRlZCB0aGUgbGlmZXRpbWUgaW4gdGhlIFJBcyBwZXJpb2RpY2FsbHkgKGku ZS4sIHNlbmQgMi41aCwga2VlcCBpdCBjb3VudGluZyBkb3duIGFuZCBhdCBzYXkgMS4yNWgsIHJl c2V0IHRvIHRoZSAyLjVoKS4gVGhvdWdoIGV2ZW4gdGhpcyBpcyBmbGF3ZWQgYXMgdGhlIGxpZmV0 aW1lcyBhcmUgcmVsYXRpdmUgYW5kIGRlcGVuZGluZyBvbiB3aGVuIHBhY2tldHMgYXJlIHJlY2Vp dmVkL3Byb2Nlc3NlZCBhbmQgdGhlIGNsb2NrcyB0aWNrLCB5b3UgbWF5IGhhdmUgc21hbGwgKGEg ZmV3IHNlY29uZHMpIGRyaWZ0IGFueXdheS4NCg0KTm90IHN1cmUgd2h5IGEgZGV2aWNlIG5lZWRz IHRvIGxpc3RlbiB0byBSQXMgd2hpbGUgaXQgd2FudHMgdG8gc2xlZXAuIFdoZW4gaXQgd2FrZXMg dXAsIGl0IGNhbiBhbHdheXMgZG8gYW4gUlMgKGlmIGl0IGZpbmRzIGl0IGhhc24ndCBtb3ZlZCBh cyB0aGUgV2lmaSBpcyBzdGlsbCB0aGVyZSkuIFRoaXMgc2VlbXMgdG8gYmUgd2hhdCBodHRwczov L3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNjc3NS5odG1sI3NlY3Rpb24tNS44LjIgc3VnZ2Vz dHMgdG8gZG8uDQoNCi0gQmVybmllDQoNCu+7v09uIDQvOC8yMCwgNzozOSBQTSwgIk93ZW4gRGVM b25nIiA8b3dlbkBkZWxvbmcuY29tPiB3cm90ZToNCg0KICAgIElmIHlvdSBkb27igJl0IGNhcCB0 aGUgdmFsaWQgbGlmZXRpbWUsIHlvdSB3b27igJl0IHNvbHZlIHRoZSBiYXR0ZXJ5IGxpZmUgcHJv YmxlbSByYWlzZWQgYnkgTG9yZW56bywgYmVjYXVzZSBSQXMgd2lsbCBiZSBjb25zdGFudGx5IGNv dW50aW5nIGRvd24uDQogICAgDQogICAgSU1ITywgaXTigJlzIGJldHRlciB0byBjYXAgYm90aCBs aWZldGltZXMgbG9jYWxseS4gQXMgbG9uZyBhcyB0aGUgcm91dGVyIHJlbWFpbnMgdXAsIGl04oCZ cyBnb2luZyB0byBnZXQgcmVmcmVzaGVkIGJ5IHRoZSBmcmVzaCBSQSBhbnl3YXkuIEkgdGhpbmsg dGhhdCB0aGUgbGlmZXRpbWVzIHNob3VsZCBiZSBsb25nIGVub3VnaCB0aGF0IG1vc3QgQ1BFIG91 dGFnZXMgd291bGQgbGlrZWx5IGJlIGFkZHJlc3NlZCAoZS5nLiA5MDAwIHNlY29uZHMgPSAyLjUg aG91cnMsIG9yLCBpZiB5b3Ugd2FudCB0byBiZSBtb3JlIGNvbnNlcnZhdGl2ZSwgODY0MDAgc2Vj b25kcyA9IDEgZnVsbCBkYXkpLg0KICAgIA0KICAgIElmIHlvdXIgb25seSBDUEUgd2VudCBkb3du IGZvciBhIGRheSBhbmQgbm9ib2R5IGZpeGVkIGl0LCBsb3NzIG9mIGxvbmctbGl2ZWQgbG9jYWwg Zmxvd3MgaXMgcHJvYmFibHkgZ29pbmcgdG8gYmUgdGhlIGxlYXN0IG9mIHlvdXIgcHJvYmxlbXMu DQogICAgDQogICAgVGhlc2UgU0hPVUxEIGJlIHJlY29tbWVuZGVkIHZhbHVlcyB3aXRoIGEgcmVx dWlyZW1lbnRzIGZvciBtYW51ZmFjdHVyZXJzIHRvIHBpY2sgc2FuZSBkZWZhdWx0cyBmb3IgdGhl aXIgdGFyZ2V0IGF1ZGllbmNlLiBBZG1pbmlzdHJhdG9ycyBTSE9VTEQgYmUgYWJsZSB0byBjb25m aWd1cmUgZGlmZmVyZW50IHZhbHVlcyBhY2NvcmRpbmcgdG8gdGhlaXIgcHJlZmVyZW5jZXMuDQog ICAgDQogICAgT3dlbg0KICAgIA0KICAgIA0KICAgID4gT24gQXByIDgsIDIwMjAsIGF0IDA3OjU3 ICwgQmVybmllIFZvbHogKHZvbHopIDx2b2x6PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPiB3 cm90ZToNCiAgICA+IA0KICAgID4gQSBmZXcgY29tbWVudHM6DQogICAgPiANCiAgICA+IDEuIE9u ZSByZWFzb24gdG8gY2FwIHRoZSBsaWZldGltZShzKSBpbiB0aGUgQ1BFIGZvciBSQXMgaXMgdGhh dCB3aGlsZSB0aGUgU1AgY291bGQgYWRqdXN0IHRoZSBsaWZldGltZXMsIHRoYXQgaGFzIGEgZGly ZWN0IGltcGFjdCBvbiB0aGUgYW1vdW50IG9mIERIQ1B2NiB0cmFmZmljIGFzIHJlZHVjaW5nIHRo ZSBwcmVmZXJyZWQgbGlmZXRpbWUgd2lsbCBjYXVzZSB0aGUgcmVuZXdhbHMgdG8gb2NjdXIgbW9y ZSBmcmVxdWVudGx5LiBUaGF0IGlzIG9uZSByZWFzb24gd2h5IFNQcyBkbyBub3QgdXNlIHNob3J0 IHByZWZlcnJlZCBsaWZldGltZXMuIChTb21lIFNQcyBoYXZlIG1hbnkgbWlsbGlvbnMgb2YgQ1BF cy4pDQogICAgPiANCiAgICA+IDIuIEkgZG8gd29uZGVyIHdoZXRoZXIgbGVhdmluZyB0aGUgdmFs aWQgbGlmZXRpbWUgYWxvbmUgaXMgYmV0dGVyIHRoYW4gcGxheWluZyB3aXRoIGJvdGggbGlmZXRp bWVzLiBGb3IgbW9zdCBhcHBsaWNhdGlvbnMgdGhhdCBkb24ndCByZXF1aXJlIGxvbmcgbGl2ZWQg YWRkcmVzc2VzLCBpdCBhY2hpZXZlcyB0aGUgZGVzaXJlZCBlZmZlY3QuIEZvciB0aG9zZSB0aGF0 IHdhbnQgbG9uZyBsaXZlZCBhZGRyZXNzZXMsIGl0IGFsbG93cyBmb3IgdGhhdCAoaWYgY2FzZSBv ZiBvdXRhZ2VzIGxvbmdlciB0aGFuIHRoZSBjYXBwZWQgdmFsaWQgbGlmZXRpbWUpIC0tIGFuZCBp ZiB0aGUgYXBwbGljYXRpb24gZGVjaWRlcyB0byB0cnkgZm9yIGEgbmV3IGFkZHJlc3MsIGl0IHdp bGwgdXNlIG9uZSBpbiBhIG5ldyBwcmVmaXggaWYgb25lIHdhcyBhZHZlcnRpc2VkLg0KICAgID4g DQogICAgPiAtIEJlcm5pZSANCiAgICA+IA0KICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCiAgICA+IEZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYg T2YgRmVybmFuZG8gR29udA0KICAgID4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCA4LCAyMDIwIDg6 MDAgQU0NCiAgICA+IFRvOiBJUHY2IE9wZXJhdGlvbnMgPHY2b3BzQGlldGYub3JnPg0KICAgID4g U3ViamVjdDogW3Y2b3BzXSBjcGUtc2xhYWMtcmVudW06IFByb3Bvc2VkIHRleHQgZm9yIHByZWZp eCBsaWZldGltZXMNCiAgICA+IA0KICAgID4gRm9sa3MsDQogICAgPiANCiAgICA+IEluIHRoaXMg cmVjZW50IHRocmVhZCBvbiBjcGUtc2xhYWMtcmVudW0sIHRoZXJlIHdhcyBhIHByb3Bvc2FsIHRv IGFkZCB0ZXh0IHRvIHRoZSBkcmFmdCwgYW5kIEkgcHJvbWlzZWQgSSB3b3VsZCBzdGFydCBhIG5l dyB0aHJlYWQganVzdCBpbiBjYXNlIHNvbWVib2R5IG1pc3NlZCB0aGUgY2hhbmNlIHRvIHJldmll dyBpbiB0aGUgcmF0aGVyIGxvbmcgdGhyZWFkLg0KICAgID4gDQogICAgPiBUaGlzIHRleHQgaXMg bWVhbnQgdG8gcmVmbGVjdCB0aGUgY29tbWVudHMgZnJvbSBQaGlsaXAsIExvcmVuem8sIGFuZCBv dGhlcnMgKHBsZWFzZSBkbyBsZXQgbWUga25vdyBpZiBJIG1pc3VuZGVyc3Rvb2Qgd2hhdCB5b3Ug bWVhbikuIFRoZSB0ZXh0IGlzOg0KICAgID4gDQogICAgPiAtLS0tIGN1dCBoZXJlIC0tLS0NCiAg ICA+IFRoZSBWYWxpZCBMaWZldGltZSBhbmQgUHJlZmVycmVkIExpZmV0aW1lIG9mIFBJT3MgaGF2 ZSBkaXJlY3QgaW1wYWN0IG9uIHR3byBkaWZmZXJlbnQgYXNwZWN0czoNCiAgICA+IA0KICAgID4g KiBUaGUgYW1vdW50IG9mIHRpbWUgaG9zdHMgbWF5IGVuZCB1cCBlbXBsb3lpbmcgc3RhbGUgbmV0 d29yayBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIChzZWUgW2RyYWZ0LWlldGYtdjZvcHMtc2xh YWMtcmVudW1dKS4NCiAgICA+IA0KICAgID4gKiBUaGUgYW1vdW50IG9mIHRpbWUgQ3VzdG9tZXIg RWRnZSByb3V0ZXJzIHdvdWxkIG5lZWQgdG8gcGVyc2lzdCB0cnlpbmcgdG8gZGVwcmVjYXRlIHN0 YWxlIG5ldHdvcmsgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiAodG8gaGFuZGxlIGNhc2VzIHdo ZXJlIG5vZGVzIG1pc3MgUm91dGVyIEFkdmVydGlzZW1lbnRzIGFuZCB0aHVzIHN0aWxsIGNvbnNp ZGVyIHRoZSBzdGFsZSBpbmZvcm1hdGlvbiBhcyB2YWxpZCkuDQogICAgPiANCiAgICA+IEFzIGEg cmVzdWx0LCBDUEUgUm91dGVycyBTSE9VTEQgb3ZlcnJpZGUgdGhlIGRlZmF1bHQgIlByZWZlcnJl ZCBMaWZldGltZSIgYW5kICJWYWxpZCBMaWZldGltZSIgdmFsdWVzIGZyb20gW1JGQzQ4NjFdLCBh bmQgZW1wbG95IHNob3J0ZXIgdmFsdWVzIHRvIG1pdGlnYXRlIHRoZSBhZm9yZW1lbnRpb25lZCBl ZmZlY3QsIHdoaWxlIGNvbXBseWluZyB3aXRoIHRoZSByZXF1aXJlbWVudCBmcm9tIFNlY3Rpb24g Mi4xIG9mIHRoaXMgZG9jdW1lbnQsIGFuZCB0aGUgcmVjb21tZW5kYXRpb25zIGluIFJGQzc3NzIu IFRoaXMgZG9jdW1lbnQgUkVDT01NRU5EUyB0aGF0IEN1c3RvbWVyIEVkZ2UgUm91dGVyIHNldCB0 aGUgUm91dGVyIExpZmV0aW1lIGFuZCBQSU8gUHJlZmVycmVkIExpZmV0aW1lIHRvIDI3MDAgc2Vj b25kcyAoNDUgbWludXRlcykgYW5kIHRoZSBQSU8gVmFsaWQgTGlmZXRpbWUgdG8gODY0MDAgc2Vj b25kcyAoMSBkYXkpLg0KICAgID4gDQogICAgPiBXZSBub3RlIHRoYXQgYSBDUEUgUm91dGVyIG5l ZWQgbm90IGVtcGxveSB0aGUgKHBvc3NpYmx5IGxvbmcpIERIQ1B2Ni1QRCBsZWFzZSB0aW1lcyBp biB0aGUgVmFsaWQgTGlmZXRpbWUgYW5kIFByZWZlcnJlZCBMaWZldGltZSBvZiBQSU9zIHNlbnQg aW4gUm91dGVyIEFkdmVydGlzZW1lbnRzIG1lc3NhZ2VzIHRvIGFkdmVydGlzZSBzdWItcHJlZml4 ZXMgb2YgdGhlIGxlYXNlZCBwcmVmaXguIEluc3RlYWQsIENQRSBSb3V0ZXJzIFNIT1VMRCB1c2Ug c2hvcnRlciB2YWx1ZXMgZm9yIHRoZSBWYWxpZCBMaWZldGltZSBhbmQgUHJlZmVycmVkIExpZmV0 aW1lIG9mIFBJT3MsIHNpbmNlIHN1YnNlcXVlbnQgUm91dGVyIEFkdmVydGlzZW1lbnQgbWVzc2Fn ZXMgd2lsbCBuZXZlcnRoZWxlc3MgcmVmcmVzaCB0aGUgYXNzb2NpYXRlZCBsaWZldGltZXMsIGxl YWRpbmcgdG8gdGhlIHNhbWUgZWZmZWN0aXZlIGxpZmV0aW1lcyBhcyBzcGVjaWZpZWQgYnkgdGhl IERIQ1B2Ni1sZWFzZSB0aW1lLg0KICAgID4gLS0tIGN1dCBoZXJlIC0tLS0NCiAgICA+IA0KICAg ID4gDQogICAgPiBUaGUgYWJvdmUgY2hhbmdlIHRhY2tsZXMgdG8gZGlmZmVyZW50IGlzc3VlczoN CiAgICA+IA0KICAgID4gKiBTYW5lciBsaWZldGltZXMgdGhhdCBhdCBsZWFzdCBhbGxvdyBmb3Ig cHJvcGVyIGdhcmJhZ2UgY29sbGVjdGlvbiBpbiBhIHRpbWVsaWVyIG1hbm5lci4NCiAgICA+IA0K ICAgID4gKiBJbiB0aGUgdHlwaWNhbCBzY2VuYXJpbyAoYnV0IGRlcGVuZGluZyBvbiBESENQdjYg c2VydmVyIHBhcmFtZXRlcnMpLCB0aGUgREhDUHY2LVBEIGxlYXNlZCB3aWxsIGJlIGxvbmdlciB0 aGFuIHRoZSBQSU8gbGlmZXRpbWVzIGFkdmVydGlzZWQgYnkgdGhlIENFIFJvdXRlciwgYW5kIHRo ZSBDRSBSb3V0ZXIgd2lsbCByZW5ldyB0aGUgcHJlZml4IGxlYXNlIHdlbGwgYmVmb3JlIHRoZSBQ SU8gbGlmZXRpbWVzIG5lZWQgdG8gYmUgYWRqdXN0ZWQvcmVkdWNlZCAodG8gYXZvaWQgaGF2aW5n IFBJTyBsaWZldGltZXMgdGhhdCBzcGFuIHBhc3QgdGhlIGRoY3B2Ni1wZCBsZWFzZSkuIFRoZSBy ZXN1bHQgaXMgdGhhdCwgaW4gcHJhY3RpY2UsIHRoZSBDRSBSb3V0ZXJzIHdvdWxkIHNlbmQgUkFz IHRoYXQgYWx3YXlzIGNvbnRhaW4gdGhlIHNhbWUgbGlmZXRpbWUgdmFsdWVzLCB0aHVzIGF2b2lk aW5nIHRoZSBiYXR0ZXJ5IGNvbnN1bXB0aW9uIHByb2JsZW0gbWVudGlvbmVkIGJ5IExvcmVuem8u DQogICAgPiANCiAgICA+IFRob3VnaHRzPw0KICAgID4gDQogICAgPiBUaGFua3MhDQogICAgPiAN CiAgICA+IENoZWVycywNCiAgICA+IC0tDQogICAgPiBGZXJuYW5kbyBHb250DQogICAgPiBTSTYg TmV0d29ya3MNCiAgICA+IGUtbWFpbDogZmdvbnRAc2k2bmV0d29ya3MuY29tDQogICAgPiBQR1Ag RmluZ2VycHJpbnQ6IDY2NjYgMzFDNiBENDg0IDYzQjIgOEZCMSBFM0M0IEFFMjUgMEQ1NSAxRDRF IDc0OTINCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IHY2b3BzIG1haWxpbmcg bGlzdA0KICAgID4gdjZvcHNAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdjZvcHMNCiAgICA+IA0KICAgID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IHY2b3BzIG1haWxpbmcgbGlzdA0KICAg ID4gdjZvcHNAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCiAgICANCiAgICANCg0K From nobody Wed Apr 8 17:22:23 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2063A1A7D for ; Wed, 8 Apr 2020 17:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGMQtMQqtOL7 for ; Wed, 8 Apr 2020 17:22:20 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1099B3A1A7B for ; Wed, 8 Apr 2020 17:22:18 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 0390MCQa714849 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Apr 2020 17:22:12 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 0390MCQa714849 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586391733; bh=rXf8AiS2KRYncG52fsxG6FyP6Kq8sB/klzk0w750sQM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=5Grs/TM3cZORJF7vIK8KE0fSVf/6FHFucf4Kj1o7sv+SmQkQwaUhLbNdBXAvczKSC LL0CrPx9H+2uIavSCb53xi8ZiQj9HNzuf4j5UEebaDxpwTvUW1UMWzJA/wHX7QBV2L QVr+kbx7RRxs5fY3+nem14YQJUde8xBbH1TBl8h0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <37AB379F-E51F-43DA-B9CA-A05845460B77@cisco.com> Date: Wed, 8 Apr 2020 17:22:11 -0700 Cc: Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <58574463-30B0-4C7E-B520-C8E9DCFE009C@delong.com> References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> <5FF0E1F8-333E-4E8F-A2AD-95B05C7473BB@delong.com> <37AB379F-E51F-43DA-B9CA-A05845460B77@cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Wed, 08 Apr 2020 17:22:13 -0700 (PDT) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 00:22:22 -0000 > On Apr 8, 2020, at 17:07 , Bernie Volz (volz) wrote: >=20 >> If you don=E2=80=99t cap the valid lifetime, you won=E2=80=99t = solve the battery life problem raised by Lorenzo, because RAs will be = constantly counting down. >=20 > Not sure I understand this. Yes, the valid lifetime in the RA would be = changing, but how does that matter if the RA comes anyway? Either you = sleep ignoring RAs or you are up and processing them. Also, if you cap = the valid lifetime at 2.5 hours, an RA at time X has a lifetime which = ends a X + 2.5h, and if another RA comes 1 minute later with a capped = valid lifetime, it will now ends at X + 1m + 2.5h. How does this save = battery life as it still is a time change? Without getting too deep into reiterating Lorenzo=E2=80=99s message, = apparently there=E2=80=99s an optimization in a lot of portable/mobile = devices that ignores duplicate RAs where nothing has changed using a lot = less power than it takes to process a new RA. If the RA valid lifetime is decrementing, then the phone will process it = as a new RA. Apparently the phone isn=E2=80=99t doing any math, just a straight = compare of the original RA and the current one. > The only way you would avoid a change in time is if the CPE also only = updated the lifetime in the RAs periodically (i.e., send 2.5h, keep it = counting down and at say 1.25h, reset to the 2.5h). Though even this is = flawed as the lifetimes are relative and depending on when packets are = received/processed and the clocks tick, you may have small (a few = seconds) drift anyway. Or if you simply ignore the RA since it=E2=80=99s identical to the = previous one. Yes, this means that the lifetime doesn=E2=80=99t get = reset, but I=E2=80=99m guessing that phones using this optimization = probably trigger an RS when the timers get close to 0. Not sure of the details, feel free to ask Lorenzo. > Not sure why a device needs to listen to RAs while it wants to sleep. = When it wakes up, it can always do an RS (if it finds it hasn't moved as = the Wifi is still there). This seems to be what = https://www.rfc-editor.org/rfc/rfc6775.html#section-5.8.2 suggests to = do. IMHO, that=E2=80=99s perfectly fine, too. Again, it was a concern = expressed by Lorenzo. If you have further questions on it, ask him. = Nonetheless, by capping the valid timer, we get a few gains and I still = don=E2=80=99t see a disadvantage to doin it. Owen >=20 > - Bernie >=20 > =EF=BB=BFOn 4/8/20, 7:39 PM, "Owen DeLong" wrote: >=20 > If you don=E2=80=99t cap the valid lifetime, you won=E2=80=99t = solve the battery life problem raised by Lorenzo, because RAs will be = constantly counting down. >=20 > IMHO, it=E2=80=99s better to cap both lifetimes locally. As long as = the router remains up, it=E2=80=99s going to get refreshed by the fresh = RA anyway. I think that the lifetimes should be long enough that most = CPE outages would likely be addressed (e.g. 9000 seconds =3D 2.5 hours, = or, if you want to be more conservative, 86400 seconds =3D 1 full day). >=20 > If your only CPE went down for a day and nobody fixed it, loss of = long-lived local flows is probably going to be the least of your = problems. >=20 > These SHOULD be recommended values with a requirements for = manufacturers to pick sane defaults for their target audience. = Administrators SHOULD be able to configure different values according to = their preferences. >=20 > Owen >=20 >=20 >> On Apr 8, 2020, at 07:57 , Bernie Volz (volz) = wrote: >>=20 >> A few comments: >>=20 >> 1. One reason to cap the lifetime(s) in the CPE for RAs is that while = the SP could adjust the lifetimes, that has a direct impact on the = amount of DHCPv6 traffic as reducing the preferred lifetime will cause = the renewals to occur more frequently. That is one reason why SPs do not = use short preferred lifetimes. (Some SPs have many millions of CPEs.) >>=20 >> 2. I do wonder whether leaving the valid lifetime alone is better = than playing with both lifetimes. For most applications that don't = require long lived addresses, it achieves the desired effect. For those = that want long lived addresses, it allows for that (if case of outages = longer than the capped valid lifetime) -- and if the application decides = to try for a new address, it will use one in a new prefix if one was = advertised. >>=20 >> - Bernie=20 >>=20 >> -----Original Message----- >> From: v6ops On Behalf Of Fernando Gont >> Sent: Wednesday, April 8, 2020 8:00 AM >> To: IPv6 Operations >> Subject: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes >>=20 >> Folks, >>=20 >> In this recent thread on cpe-slaac-renum, there was a proposal to add = text to the draft, and I promised I would start a new thread just in = case somebody missed the chance to review in the rather long thread. >>=20 >> This text is meant to reflect the comments from Philip, Lorenzo, and = others (please do let me know if I misunderstood what you mean). The = text is: >>=20 >> ---- cut here ---- >> The Valid Lifetime and Preferred Lifetime of PIOs have direct impact = on two different aspects: >>=20 >> * The amount of time hosts may end up employing stale network = configuration information (see [draft-ietf-v6ops-slaac-renum]). >>=20 >> * The amount of time Customer Edge routers would need to persist = trying to deprecate stale network configuration information (to handle = cases where nodes miss Router Advertisements and thus still consider the = stale information as valid). >>=20 >> As a result, CPE Routers SHOULD override the default "Preferred = Lifetime" and "Valid Lifetime" values from [RFC4861], and employ shorter = values to mitigate the aforementioned effect, while complying with the = requirement from Section 2.1 of this document, and the recommendations = in RFC7772. This document RECOMMENDS that Customer Edge Router set the = Router Lifetime and PIO Preferred Lifetime to 2700 seconds (45 minutes) = and the PIO Valid Lifetime to 86400 seconds (1 day). >>=20 >> We note that a CPE Router need not employ the (possibly long) = DHCPv6-PD lease times in the Valid Lifetime and Preferred Lifetime of = PIOs sent in Router Advertisements messages to advertise sub-prefixes of = the leased prefix. Instead, CPE Routers SHOULD use shorter values for = the Valid Lifetime and Preferred Lifetime of PIOs, since subsequent = Router Advertisement messages will nevertheless refresh the associated = lifetimes, leading to the same effective lifetimes as specified by the = DHCPv6-lease time. >> --- cut here ---- >>=20 >>=20 >> The above change tackles to different issues: >>=20 >> * Saner lifetimes that at least allow for proper garbage collection = in a timelier manner. >>=20 >> * In the typical scenario (but depending on DHCPv6 server = parameters), the DHCPv6-PD leased will be longer than the PIO lifetimes = advertised by the CE Router, and the CE Router will renew the prefix = lease well before the PIO lifetimes need to be adjusted/reduced (to = avoid having PIO lifetimes that span past the dhcpv6-pd lease). The = result is that, in practice, the CE Routers would send RAs that always = contain the same lifetime values, thus avoiding the battery consumption = problem mentioned by Lorenzo. >>=20 >> Thoughts? >>=20 >> Thanks! >>=20 >> Cheers, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 From nobody Wed Apr 8 17:33:22 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1863A0885 for ; Wed, 8 Apr 2020 17:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXbjKvy1Hqxt for ; Wed, 8 Apr 2020 17:33:19 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73383A087F for ; Wed, 8 Apr 2020 17:33:18 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 B9995831C9; Thu, 9 Apr 2020 02:33:15 +0200 (CEST) To: "Bernie Volz (volz)" , Owen DeLong Cc: IPv6 Operations References: <77a84b82-716d-e754-9317-8876af5e49db@si6networks.com> <5FF0E1F8-333E-4E8F-A2AD-95B05C7473BB@delong.com> <37AB379F-E51F-43DA-B9CA-A05845460B77@cisco.com> From: Fernando Gont Message-ID: Date: Wed, 8 Apr 2020 21:33:01 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <37AB379F-E51F-43DA-B9CA-A05845460B77@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 00:33:21 -0000 Hello, Bernie, On 8/4/20 21:07, Bernie Volz (volz) wrote: >> If you don’t cap the valid lifetime, you won’t solve the battery life problem raised by Lorenzo, because RAs will be constantly counting down. > > Not sure I understand this. Yes, the valid lifetime in the RA would be changing, but how does that matter if the RA comes anyway? Either you sleep ignoring RAs or you are up and processing them. Also, if you cap the valid lifetime at 2.5 hours, an RA at time X has a lifetime which ends a X + 2.5h, and if another RA comes 1 minute later with a capped valid lifetime, it will now ends at X + 1m + 2.5h. How does this save battery life as it still is a time change? Lorenzo explained that, somehow, if the RA is always the same, they can avoid waking up the mobile upon receipt of each RA. If the contents the RA change, this fails. So,to illustrate the two extremes: If the DHCP lease time is 1000 seconds (no reall.just for illustrative purposes), and you want RAs to reflect the total lifetime, then at time 0 you'd send an RA/PIO of 1000, at time 1 an RA/PIO of 999, etc (i.e. the contents change all teh time). Now, if you cap the PIO lifetimes to 100, then if the lease is 1000s, you'd advertise an RA/PIO of 100, at time 1 (while the "internally computed· lifetime at the CPE is 999), you still advertise an RA/PIO of 100. *Only* at time 901 (and if you hadn't tried to RENEW the lease), you'd had to reduce the PIO lifetimes to 99, then 98, etc., But if the lease is renewed before both the PIO preferred and valid lifetime seconds have elapsed, you'd always send RAs with the same values. And this seems to be big savings for mobile phones. That's how I understood the issue, at least. But Lorenzo or other folks might be in a better position to correct me or clarify further... 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 Apr 8 17:41:02 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3631F3A1AAE for ; Wed, 8 Apr 2020 17:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crctN3utH7u4 for ; Wed, 8 Apr 2020 17:40:57 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9DBF3A1AAD for ; Wed, 8 Apr 2020 17:40:57 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id 22so3278494pfa.9 for ; Wed, 08 Apr 2020 17:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=PmOf/4Axs6lLVcaKDMp2ZYTKGmtd+Pl/M/c+iX1YD+0=; b=S1Lkyq8Rk03SeOACOxOPMLRzPUL2FvMrcxpn+7Ic7l8zvrZ1ArdfchLW5rFHvleiH8 IRRYfOn36AEUKgdc4JW4ETquyUpHSBxr/jrUOnYFGsOAJ8GLVt2ROuIf1zVwIJbRc/ih JS5npgMQ50XA7wqybr/XWZU/le13NLfEEhAnIOuWMk2rY6ahtBhp2Ijnmu+zG92OnmCE T2P02Hw73LE+U9ZbfKGwgYhvikYjBfsDsX/p0MmEDCiZTAfP0QfVzkiRcr3A2ULmTOOG IZQVYIGcHP30JL33QqW+cdcIwVBfhSnBJQi3TmylLvfnSaqcfqDQ9PqOVCfn/kvEeh9k 5KTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=PmOf/4Axs6lLVcaKDMp2ZYTKGmtd+Pl/M/c+iX1YD+0=; b=uFjx2OpCLgi5tQ8GaBf30wjM9QKT2iBO9l/d3z6ZefsmXOVG8SNZuD4v9yCFkFzS/1 GnryiSRa77Wm77IIHuBuLQLW6QOseByU6NmTONB4arM1+frEs8Bg2mcBQH0Ppt/axjUC /bnTzReuPyYFCW1rYjaKVMgpXOaBxAF+Q6xtdr6KLrV+VNlycLuzuSV3UaN4Zhw7Fi2X 5wIb75fXgSqrypujzYG1GVoglzFEucV5G7RKvySOEETc0dUdxtveYOqor53sMYcS0QbF ZCHQaIYF0jkv07mxYCTnrd5haynGH0pti3Mncp+DiW6ai9/kbtq0iMrkdfTrMLh49bMl 5XPw== X-Gm-Message-State: AGi0PubJXpfaElOGBFGzsTRDt6RoANeVZngMxX0WYiIubigJto1dm7Hb ngjS6mrM1UGb18VQl/lp6pberGP8 X-Google-Smtp-Source: APiQypIHoaTnKJf9FrhRamvC2i/Y5nBhD4TvUnGg+iqftoH+zZ4PD6Af7XVYdKPTnNvPtjpRrL7gHQ== X-Received: by 2002:a65:6855:: with SMTP id q21mr9482072pgt.188.1586392856861; Wed, 08 Apr 2020 17:40:56 -0700 (PDT) Received: from ?IPv6:2600:8802:5900:13c4::1041? ([2600:8802:5900:13c4::1041]) by smtp.gmail.com with ESMTPSA id r63sm17841014pfr.42.2020.04.08.17.40.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Apr 2020 17:40:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Fred Baker In-Reply-To: Date: Wed, 8 Apr 2020 17:40:55 -0700 Cc: Fernando Gont , Lorenzo Colitti , "v6ops@ietf.org" , Timothy Winters Message-Id: <37BF330E-5744-40C8-9325-4532DB3BC480@gmail.com> References: To: otroan@employees.org X-Mailer: iPhone Mail (17E262) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 00:41:00 -0000 Sounds hopeful. Sent using a machine that autocorrects in interesting ways... > On Apr 8, 2020, at 10:57 AM, otroan@employees.org wrote: >=20 > =EF=BB=BF >>=20 >>>>>>>> We have timers. We are just not using them appropriately. What's th= e point of having PL and VL lifetimes in a way that they will never go off i= n any meaningful timeframe? >>>>>>> No. You are proposing to use the prefix timers for something they we= re never designed for. >>>>>>=20 >>>>>> 1) I'm proposing to use prefix timers... for timing out timers :-) >>>>>>=20 >>>>>> The Preferred Lifetime, to deprecate an otherwise preferred prefix. >>>>>> The Valid Lifetime, to invalidate the prefix. >>>>>>=20 >>>>>> Just of curiousity, may I ask what do you think they are meant for? (= of course, wasting them by using huge values not being a valid option). >>>>> They are meant to support renumbering. >>>>=20 >>>> Part of renumbering is phasing out prefixes. And this is what we are do= ing here. >>> No you are not. >>=20 >> Let's agree to disagree. >>=20 >> I put a timer for addresses. Unless there's any sort of signal that the c= onfiguration is current in a veeery reasonable period of time, I phase out t= he prefix. >=20 > I think you are mixing what you are proposing in 6man with what you are pr= oposing in v6ops. > The current draft in v6ops is reasonable, if the review comments I posted a= re included. > The added text on lifetimes in this document is not. >=20 >>> If you were doing renumbering, then you'd get two prefixes in DHCP PD. O= ne old expired (lifetimes 0), one new with lifetimes > 0. >>=20 >> This was already discussed on this mailing list. Please read draft-ietf-v= 6ops-slaac-renum. Many operators have already spoke up on the topic. I don't= have much to add in addition to what has already been said. >>=20 >>=20 >>=20 >>> If that simple operational rule was followed, then none of these tweaks a= re required. (At least for this purpose). >>=20 >> If folks had follow the simple operational plan that everyone enables v6,= and then when everyone could simply disable IPv4, we would have deployed v6= 20 years ago, and we wouldn't have the ..load of transition/co-existence me= chanisms that we have. >>=20 >> But hey, engineering is a bit about solving problems in the real world, r= ather than complaining that the problems are not solvable because the planet= should actually be spinning in the opposite direction. >=20 > I take it being condecending is your way of saying you have run out of arg= uments? >=20 > The point is that there are many ways of misconfiguring or doing the mecha= nics of prefix delegation wrong. > That doesn't mean we should adapt the standards to accommodate who do not d= o it the way it is specified. > Especially when those operational practices have bad implications on end-u= sers, and the mitigations proposed are potentially risky for the majority wh= o will never see a network "operated" this way. >=20 >>>> A core design principle of the Internet is that as long as there is a w= orking path from source to destination, communications survive possible outa= ges. >>> Oh, I'm not saying that we shouldn't make host behaviour more robust. Ra= ther the contrary. I'm just saying I don't think the proposed changes are th= e right ones. >>> Let me see if I find some spare time to write down how I would like it t= o work. Don't hold your breath. >>=20 >> We have been discussing this problem for over one year now. >=20 > Yes, you have. >>=20 >>=20 >>>>> is not a tradeoff I'm willingto make. >>>>> What's described in slaac-renum isn't a protocol problem. >>>>=20 >>>> I respect that you may have a different opinion and disagree. >>>>=20 >>>> Now, splitting your role as a participant, and your role as wg char, ma= y we have a wg call on draft-gont-6man-slaac-renum at 6man? >>> If you want me to put my chair hat on, then you need to take that to the= 6man list. >>=20 >> I did, indeed: https://mailarchive.ietf.org/arch/msg/ipv6/qO_vGJrDVMOC1fn= OGa8DquONOAs/ (at least for the second time). >=20 > Cheers, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Apr 8 17:58:44 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0973A1BAA for ; Wed, 8 Apr 2020 17:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cET6hSgyyCiF for ; Wed, 8 Apr 2020 17:58:41 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D823A1BA6 for ; Wed, 8 Apr 2020 17:58:41 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 4871580240; Thu, 9 Apr 2020 02:58:38 +0200 (CEST) To: Ted Lemon Cc: otroan@employees.org, IPv6 Operations References: <4402fcaf-b6bd-937e-3184-4bd98749de7f@si6networks.com> <93F8AEB5-242A-4178-83E1-D5F16360AA87@fugue.com> From: Fernando Gont Message-ID: Date: Wed, 8 Apr 2020 21:57:34 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <93F8AEB5-242A-4178-83E1-D5F16360AA87@fugue.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 00:58:43 -0000 On 8/4/20 20:33, Ted Lemon wrote: > I agree with your analysis about ICMPv6—thanks for that. I think that the source address selection solution can work, though—it just requires a slightly more clever algorithm than the one you proposed and then rejected. I described it in another message. FWIW, to be honest, the one described in the document had been proposed by Jen. So that's "the only one" that had been discussed, and hence made it into the appendix. > > One thing that could be done with source address selection is that if an address fails the test I described (choose the loser only if its preferred lifetime is ten minutes longer than the incumbent), you could send a router solicit for the router that advertised that prefix; if there’s no response to the solicit, then deprecate the prefix, and when there are no more references to any address on the prefix, gc any remaining addresses on that prefix and the prefix itself. I will dig and try to find the specific message. Or, if you know which one it is, please do fwd to me. There are two things to note here: THe problem with comparing lifetimes is that: 1) In order to be able to compare two PIOs from e.g. two different CPES, you depend on both of them capping the PIO lifetimes (for the lifetimes to be comparable). And then you also need the host-side update. This means that if update the host (simple, and doable in a timely manner) but are not employing updated CPEs, the mitigation doesn't work. (If I'm understanding it correctly). OTOH, the algorithms from Section 4.5 of the draft only require host-side changes. As long as you implement them at the host, you already received the benefits. In particular, the algorithm from section 4.5.1 is really striaghtforward: * Upon receipt of an RA that advertises new prefixes but not the previous one, you deprecate (un-prefer) the prefix/address (the I-D says to actually set the PL to a couple of seconds to accommodate the thoretical case where the information might be split into multiple RAs.. but in practice you wouldn't even need to wait at all). And you also set the Valid Lifetime to a value in the order one or a few dozen minutes (so, if meanwhile you receive an RA advertising the prefix, the addresses get refreshed... and otherwise, after that time has elapsed, you'd remove/invalidate them). IN the typical case where e.g. the CPE crashes and reboots, as soon as the CPE has bootstrapped, the first initial RA will provve both a new prefix, but also deprecate (unprefer) the previous one. SO the only waiting time would be the dozen minutes or so for the address to be invalidated. Of course, you could even augment this, and instead of passively waiting for a dozen minutes, you could send an RS after 5 minutes or so. But, unless I'm missing something, there wouldn't seem much to be gained. FWIW, I see RFC6724 as doing the right thing. IMO the problem is that in current implementations, the preferred/deprecated "implict flag" is severely broken: the use og insanely long lifetimes really means that you don't really keep track of whether adresses are preferred or not: for all meaningul purposes all addresses are considered "preferred" (well, except the temporary addresses that you phase out) If I have misunderstood your algorithm, please do let me know -- we're not married with any specific value, and meant to do the best we can. 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 Apr 8 18:09:59 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3612A3A1C13 for ; Wed, 8 Apr 2020 18:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3ozrLsJCpfl for ; Wed, 8 Apr 2020 18:09:56 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77FB73A1C49 for ; Wed, 8 Apr 2020 18:09:56 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id c63so2452892qke.2 for ; Wed, 08 Apr 2020 18:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=cqJGlhVZI5bHZXmu7Q3wYRxThJpMObF/d0bisLB6BeA=; b=XWmbtazBMQ9qp8oUjEwmcsgp66+bEs7OqkrTeHI3wKBEQuyDszGLigJxQXvZWTjwIb d1dISsqyfrfArVNL73m5mtqLUNZdX+CfyIZOSsS3W08buayi/a/rJqVMcP98j13D2JEU b/EY83P5UNxDyayeI7wo0wHWeuG289skV9iNPSxIK5Z/ypafHz4WbHvifovsyS5fkyPt eTPbSnkpUC5MUZqYEmUxn0bEFDhZdPJyKW8dIDeYvyPvDRVf34KUJqZ28Xc+bke8qDmR ifMcvxGrWCaPY5TvQtKs7o4vnkDBGRdKadmDe+tU9Ys650ZQmaQtysyuO9I9TEBsXV1i Bd2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=cqJGlhVZI5bHZXmu7Q3wYRxThJpMObF/d0bisLB6BeA=; b=NcHHYBjJLSAdsJQPmlHDBzUAPxkXLoHbRSNpuXDeRwtWHHLRjUEaNwTrL8gisbfplX JoewcBHw9GNHu0vggWRidqYyYvomQWErRnFnlQ9LSrUvSmTxKcyGP2YW3eqzAebMwpXd 9qFh0qhyZ9XieTU0f/k/ADnVGctEfW4NpSv8Sqk8YUbIR6B5qAUsHBUpXCIe5pi46d2a pq9BXpVOfitXDY0rAiDVrLeFIFSgSNK2UqLq/LrPC57pDMGvA9Qszp9q3aTeZc/fHTUO WnzMlQgNsiBQYVh0VGuXwT1bxegH18q33uU7eMg11xr5RJRY+Jvp/ZfBKf8c52q5lIir hPCQ== X-Gm-Message-State: AGi0PubmQEJLxCuExDEsQhUlc83WYQdHdmeC6IIMOt5ODkGMBLAK7UNs 4335oedtMF1YsGvQqxzmzbALYwPky3A= X-Google-Smtp-Source: APiQypI+VriHOJ484frWyJ9tXxzDUR8HShvCYvJn0xeoITTZINi68pH0DmM2YGjp3Hvmsxe5XptwDw== X-Received: by 2002:a05:620a:16b0:: with SMTP id s16mr9205613qkj.204.1586394595066; Wed, 08 Apr 2020 18:09:55 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:201b:83ea:1756:69e4? ([2601:18b:300:36ee:201b:83ea:1756:69e4]) by smtp.gmail.com with ESMTPSA id o7sm19764635qkm.35.2020.04.08.18.09.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Apr 2020 18:09:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 8 Apr 2020 21:09:53 -0400 Message-Id: <716E84F8-5B39-4CAD-B617-06CC1663BF9D@fugue.com> References: Cc: otroan@employees.org, IPv6 Operations In-Reply-To: To: Fernando Gont X-Mailer: iPad Mail (17E255) Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 01:09:58 -0000 You=E2=80=99re right about the two-cpe case. Sent from my iPad > On Apr 8, 2020, at 8:58 PM, Fernando Gont wrote: >=20 > =EF=BB=BFOn 8/4/20 20:33, Ted Lemon wrote: >> I agree with your analysis about ICMPv6=E2=80=94thanks for that. I think= that the source address selection solution can work, though=E2=80=94it just= requires a slightly more clever algorithm than the one you proposed and the= n rejected. I described it in another message. >=20 > FWIW, to be honest, the one described in the document had been proposed by= Jen. So that's "the only one" that had been discussed, and hence made it in= to the appendix. >=20 >=20 >> One thing that could be done with source address selection is that if an a= ddress fails the test I described (choose the loser only if its preferred li= fetime is ten minutes longer than the incumbent), you could send a router so= licit for the router that advertised that prefix; if there=E2=80=99s no resp= onse to the solicit, then deprecate the prefix, and when there are no more r= eferences to any address on the prefix, gc any remaining addresses on that p= refix and the prefix itself. >=20 > I will dig and try to find the specific message. Or, if you know which one= it is, please do fwd to me. >=20 > There are two things to note here: > THe problem with comparing lifetimes is that: > 1) In order to be able to compare two PIOs from e.g. two different CPES, y= ou depend on both of them capping the PIO lifetimes (for the lifetimes to be= comparable). And then you also need the host-side update. >=20 > This means that if update the host (simple, and doable in a timely manner)= but are not employing updated CPEs, the mitigation doesn't work. (If I'm un= derstanding it correctly). >=20 > OTOH, the algorithms from Section 4.5 of the draft only require host-side c= hanges. As long as you implement them at the host, you already received the b= enefits. >=20 >=20 > In particular, the algorithm from section 4.5.1 is really striaghtforward:= >=20 > * Upon receipt of an RA that advertises new prefixes but not the previous o= ne, you deprecate (un-prefer) the prefix/address (the I-D says to actually s= et the PL to a couple of seconds to accommodate the thoretical case where th= e information might be split into multiple RAs.. but in practice you wouldn'= t even need to wait at all). And you also set the Valid Lifetime to a value i= n the order one or a few dozen minutes (so, if meanwhile you receive an RA a= dvertising the prefix, the addresses get refreshed... and otherwise, after t= hat time has elapsed, you'd remove/invalidate them). >=20 >=20 > IN the typical case where e.g. the CPE crashes and reboots, as soon as the= CPE has bootstrapped, the first initial RA will provve both a new prefix, b= ut also deprecate (unprefer) the previous one. SO the only waiting time woul= d be the dozen minutes or so for the address to be invalidated. >=20 > Of course, you could even augment this, and instead of passively waiting f= or a dozen minutes, you could send an RS after 5 minutes or so. But, unless I= 'm missing something, there wouldn't seem much to be gained. >=20 >=20 > FWIW, I see RFC6724 as doing the right thing. IMO the problem is that in c= urrent implementations, the preferred/deprecated "implict flag" is severely b= roken: the use og insanely long lifetimes really means that you don't really= keep track of whether adresses are preferred or not: for all meaningul purp= oses all addresses are considered "preferred" (well, except the temporary ad= dresses that you phase out) >=20 >=20 > If I have misunderstood your algorithm, please do let me know -- we're not= married with any specific value, and meant to do the best we can. >=20 > Thanks! >=20 > Cheers, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From nobody Thu Apr 9 05:48:46 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172B13A0A74 for ; Thu, 9 Apr 2020 05:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGxtPGxb5RYD for ; Thu, 9 Apr 2020 05:48:42 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8CF3A0A6C for ; Thu, 9 Apr 2020 05:48:40 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jMWbe-0000I6C; Thu, 9 Apr 2020 14:48:30 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> <5079EE4E-D48F-4C8A-ABBC-FB71DDFFC003@delong.com> In-reply-to: Your message of "Wed, 8 Apr 2020 17:01:22 -0700 ." <5079EE4E-D48F-4C8A-ABBC-FB71DDFFC003@delong.com> Date: Thu, 09 Apr 2020 14:48:27 +0200 Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 12:48:44 -0000 > > Just like you can have static IPv4 addresses and still hand them out using > > DHCPv4. > > Nope. > > Theyre fixed dynamic addresses at that point, not static addresses. Call it fixed dynamic address. What does that even mean? It is dynamic but never changing? > Similarly, you can receive a fixed dynamic prefix via DHCP-PD, but > its still being issued to you dynamically and it wont keep working > if you dont renew the lease. That very much depends on the situation. In many cases, you can keep using a 'fixed dynamic' IPv4 address without running a DHCP client. In other cases it may not work. But the issue is not whether external communication works or not. When the router is down, there is no external communication, whether the prefix is still valid or not. However, that does not mean that local connections should break. The only thing I'm asking it to allow the operator to configure things differently based on the local situation. Not that it should be the default or happen automatically. From nobody Thu Apr 9 06:13:51 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C253A0852 for ; Thu, 9 Apr 2020 06:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Mkn8B-I1U4I3 for ; Thu, 9 Apr 2020 06:13:45 -0700 (PDT) Received: from mail-qv1-xf44.google.com (mail-qv1-xf44.google.com [IPv6:2607:f8b0:4864:20::f44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB803A0849 for ; Thu, 9 Apr 2020 06:13:45 -0700 (PDT) Received: by mail-qv1-xf44.google.com with SMTP id q73so5427075qvq.2 for ; Thu, 09 Apr 2020 06:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=mQ6bdAb8An5aTTWbBrMwvh7X1KX85hrKUs/hlAdfEt8=; b=lS4IaoSzZxzs+yb6GCumdVXqRBQQ8NShBKsCaMBEnIVmzzz2QfoQVuePHeYcQMlusB 9PqU7LoGos4B6yRClZIQ6CE3AFL3aCqdvLdkU/5P/W/GBJGTA+riSCtgKGJbxh28XgI7 91J8jckkVfglPS0C0IvizM+b7RnqwZBu1CgMqL1AozShspxd1FTRC+uZ+1TPQ/VJmOys UP2N5QFJHGY15GOC6Tj/panGIk0acwbUH2TQVzw9RjDrswpobIzzQ2Z2G0ncB/6yg1t0 lhID+TbPcYOe+J8QLwcoquboJxgEkPjgMJuwZn3iqlmpcnD7Ui/eW8axVsghTHFqseFS M2ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=mQ6bdAb8An5aTTWbBrMwvh7X1KX85hrKUs/hlAdfEt8=; b=iupIhZMzYBiiGT2krlH40JJpFud4LtZCMFebOE5WZbyu++5rG9DULUV2BNHqdzB2oQ F2B5ssGv++/W7GTEyJQmk1INPVnnVvnwXjK45ZGEuGGTNyTlztiSlq/znQlyPuvZmhpK JAIoeA7EV0jvWjdJmhS3dRTaxi4O8Ag4iFXExx0VdpoZzcCHzfj2eFIMJ0ajDbq04OMa HZsw/OChDdL7BktQjfbwtZSSWdUaVu+pHxwWBC1m7/cZuD4lfoSAoaRQdIloSECoSW3C oswluSx66a0NniqgFLmq9P7puPOHCdnWgwMGpKzwaQlXPZuwhWqf45r/s+Yk4BO+/zb6 1m3w== X-Gm-Message-State: AGi0PuZGCPajZ+g9EDyWlZ5/3mnr7uw70GLqBrdAH2sdibJ/Cm3EAvE3 vVIrRJeIZF51M0qrlaDJICDnj1gfMGM= X-Google-Smtp-Source: APiQypIpUgXlbldDQgcxFVkh5NHiuxShkVEm7D9mvzGyOcJSc99tn52/QEr8QTSOjXzSqLCynieb7w== X-Received: by 2002:ad4:56e3:: with SMTP id cr3mr7115896qvb.119.1586438023661; Thu, 09 Apr 2020 06:13:43 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:201b:83ea:1756:69e4? ([2601:18b:300:36ee:201b:83ea:1756:69e4]) by smtp.gmail.com with ESMTPSA id a19sm21398788qtp.5.2020.04.09.06.13.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Apr 2020 06:13:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Thu, 9 Apr 2020 09:13:42 -0400 Message-Id: <2B9CCF8A-87FE-4C5B-96FD-B8C5FE42F9F8@fugue.com> References: Cc: v6ops@ietf.org In-Reply-To: To: Philip Homburg X-Mailer: iPad Mail (17E255) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 13:13:49 -0000 On Apr 9, 2020, at 8:48 AM, Philip Homburg wrot= e: > But the issue is not whether external communication works or not. When the= > router is down, there is no external communication, whether the prefix is > still valid or not. >=20 > However, that does not mean that local connections should break. I think there=E2=80=99s a sort of consensus that the best practice for deali= ng with this is that the CPE router should always be advertising a ULA along= with whatever GUA it has. If you don=E2=80=99t do this, then a flash renum= bering event on the part of the ISP, which we have to allow for, will also b= reak connections between devices on the local network. E.g., if you are doi= ng a backup to your NAS, that will suddenly fail and restart. RFC 7084 doesn=E2=80=99t make this an explicit requirement=E2=80=94see secti= on 4.3. It does correctly document how ULAs should be handled, but does not= require that this be done. I=E2=80=99d be curious whether there=E2=80=99s still any debate about whethe= r ULAs should be configured or not. I have heard from some folks that link-= local addresses are sufficient, and should be used for all link-local commun= ication, and that certainly is another way of addressing this problem. This= relies, however, on the destination address being a link-local address, and= of course doesn=E2=80=99t work if the CP network is subnetted. That=E2=80=99= s almost always the case nowadays, but e.g. if you have a stub network for I= oT devices, or a guest network that=E2=80=99s isolated from the home network= , that may not be adequate. From nobody Thu Apr 9 06:37:54 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1060F3A0B56 for ; Thu, 9 Apr 2020 06:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq0mMYqSRQg1 for ; Thu, 9 Apr 2020 06:37:50 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1403A0B52 for ; Thu, 9 Apr 2020 06:37:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jMXNJ-0000MNC; Thu, 9 Apr 2020 15:37:45 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <2B9CCF8A-87FE-4C5B-96FD-B8C5FE42F9F8@fugue.com> In-reply-to: Your message of "Thu, 9 Apr 2020 09:13:42 -0400 ." <2B9CCF8A-87FE-4C5B-96FD-B8C5FE42F9F8@fugue.com> Date: Thu, 09 Apr 2020 15:37:45 +0200 Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 13:37:52 -0000 > > However, that does not mean that local connections should break. > > I think theres a sort of consensus that the best practice for > dealing with this is that the CPE router should always be advertising > a ULA along with whatever GUA it has. If you dont do this, then > a flash renumbering event on the part of the ISP, which we have to > allow for, will also break connections between devices on the local > network. E.g., if you are doing a backup to your NAS, that will > suddenly fail and restart. Note, the scenario is where I have a fixed prefix. But for technical reason I'm forced to run DHCPv6 PD. So, no flash renumbering expeced. I'm not against using ULAs, but what do you put in DNS? Do you make separate internal zones with ULAs? In the case of a static prefix, just listing public addresses is way more convenient. From nobody Thu Apr 9 07:07:16 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D2F3A0062 for ; Thu, 9 Apr 2020 07:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5H48BCO3ezGj for ; Thu, 9 Apr 2020 07:07:12 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB19F3A0060 for ; Thu, 9 Apr 2020 07:07:12 -0700 (PDT) Received: from astfgl.hanazo.no (dhcp217197164175.blix.com [217.197.164.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 7D9F94E11D57; Thu, 9 Apr 2020 14:07:11 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 5E8B43198294; Thu, 9 Apr 2020 16:07:04 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Thu, 9 Apr 2020 16:07:03 +0200 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2E01C362-29E0-4AB3-84CA-E63D2D734F5F@employees.org> References: <2B9CCF8A-87FE-4C5B-96FD-B8C5FE42F9F8@fugue.com> To: Philip Homburg X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 14:07:15 -0000 >>> However, that does not mean that local connections should break. >>=20 >> I think theres a sort of consensus that the best practice for >> dealing with this is that the CPE router should always be advertising >> a ULA along with whatever GUA it has. If you dont do this, then >> a flash renumbering event on the part of the ISP, which we have to >> allow for, will also break connections between devices on the local >> network. E.g., if you are doing a backup to your NAS, that will >> suddenly fail and restart. >=20 > Note, the scenario is where I have a fixed prefix. But for technical > reason I'm forced to run DHCPv6 PD. So, no flash renumbering expeced. >=20 > I'm not against using ULAs, but what do you put in DNS? Do you make = separate > internal zones with ULAs? >=20 > In the case of a static prefix, just listing public addresses is way = more > convenient.=20 Indeed. And for that reason there is no consensus that ULA should be = recommended in home networks either. =46rom what I have seen trying to make multi-homing work, I'm not sure I = would trust host stack behaviour with regards to source address = selection having link-local, ULA and global either. (and link-local addresses really only work with applications = specifically supporting it). And I'd expect the ULA might change whenever you change CPE too (if = that's Ted's case), so even more complexity. Cheers, Ole= From nobody Thu Apr 9 08:00:34 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CA93A095E for ; Thu, 9 Apr 2020 08:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcLShXYgo0tp for ; Thu, 9 Apr 2020 08:00:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C346C3A094C for ; Thu, 9 Apr 2020 08:00:26 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jMYf8-0000KbC; Thu, 9 Apr 2020 17:00:14 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <2B9CCF8A-87FE-4C5B-96FD-B8C5FE42F9F8@fugue.com> <2E01C362-29E0-4AB3-84CA-E63D2D734F5F@employees.org> In-reply-to: Your message of "Thu, 9 Apr 2020 16:07:03 +0200 ." <2E01C362-29E0-4AB3-84CA-E63D2D734F5F@employees.org> Date: Thu, 09 Apr 2020 17:00:13 +0200 Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 15:00:29 -0000 > From what I have seen trying to make multi-homing work, I'm not > sure I would trust host stack behaviour with regards to source > address selection having link-local, ULA and global either. For ULA and global, the longest prefix match should get the right one if the policy table is not updated to include a label for ULA. No clue how many stacks would get that wrong. > And I'd expect the ULA might change whenever you change CPE too > (if that's Ted's case), so even more complexity. If the new router picks a new ULA prefix then hosts will have two ULA prefixes until the old one expires. As long as the valid lifetime of the old one is high enough, long connections should be unaffected. From nobody Thu Apr 9 09:01:09 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D409D3A0B4E for ; Thu, 9 Apr 2020 09:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VehyGNWQbnq for ; Thu, 9 Apr 2020 09:01:05 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11843A0AF3 for ; Thu, 9 Apr 2020 09:00:43 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id b4so3377744qvw.8 for ; Thu, 09 Apr 2020 09:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EnFJXT8wVvDulbbKMe+YmuCeCnj4C+j7Crp0bp+N0cg=; b=cLqEMyvJHsHTBnbMuaXIeWJjvSXMiVmaZ15t7+NukLWaDb/+ClN4/oiSqP9nSGYT8t rAqNXlBvCQUsjbnUOfsC/5g65xaxzo49NurYbfljeMoHfZxBVqItbWn9FKDKAvANX/cY X431JiD8Ye9HCWLfADpCknI8PUTfgXm/1bB8lbnPvcRKE/4rxzK6EVMnZPOwwtTrTOYr s9NtXQqVSnpngR4eZUZKO+vtu6CEuxJ9KRhzsiu2PGkyaA69mGJx6qV5cE6zaeNVk931 BEfstSbDc9U2z8Bk9YwrR/ikifl84IetOBYC5XXklmBkRCIZbHdjY3CCW+0QFlwL2gtq CkGg== 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=EnFJXT8wVvDulbbKMe+YmuCeCnj4C+j7Crp0bp+N0cg=; b=jx0OqYfogEdUqR7fkzR0CaRfUH7zXvpzDodTTYVlT4zGcMOMFHXkX5pgdmyQvP8U0M uq/zRaM6tcKoMMvkIjrMIHGAh095UGqkpunTU9D8Ic+FAS4Y5HRRFV0OVyREMJfKaB+q PxG/BtQGy4W7C8ughKuHRx7gZd6nwFbnB907cJqAbD3s2Gy3sl4WbS751kVkA07jy/ts NZMFRjtxWB+e9eFsGQq/rkPECZtJ8awmw9ux5macwA+qBHohnmhDgYTyKoAOCVkEGbtY g4SF14XaHsRuprmArTQwZ2be5XztAizKX50XpojSR0U2Cv6Vzofh87H/O8JP/60yG+jJ VeQg== X-Gm-Message-State: AGi0PuYuBlci71FO6N/z4KeotdD82uO+CAYJSThjmmCmHzV+EHEe96BU IMHbeJLgj0pGVscrL1iM9k9VUJqdADY= X-Google-Smtp-Source: APiQypKttJiwvYCeutqZwIXaKFiR4WMyy5p/tCzw6poY+QM/R993iXVq9jc6vNiytotNpDpxUxqc8w== X-Received: by 2002:a0c:f9d0:: with SMTP id j16mr769845qvo.158.1586448042705; Thu, 09 Apr 2020 09:00:42 -0700 (PDT) Received: from [192.168.1.241] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id o187sm11403763qkb.40.2020.04.09.09.00.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 09:00:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.6\)) From: Ted Lemon In-Reply-To: <2E01C362-29E0-4AB3-84CA-E63D2D734F5F@employees.org> Date: Thu, 9 Apr 2020 12:00:37 -0400 Cc: Philip Homburg , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6A3A994C-7A96-49AC-B44E-67EA662C8D88@fugue.com> References: <2B9CCF8A-87FE-4C5B-96FD-B8C5FE42F9F8@fugue.com> <2E01C362-29E0-4AB3-84CA-E63D2D734F5F@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.3622.0.6) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 16:01:08 -0000 On Apr 9, 2020, at 10:07 AM, otroan@employees.org wrote: >> Note, the scenario is where I have a fixed prefix. But for technical >> reason I'm forced to run DHCPv6 PD. So, no flash renumbering expeced. >>=20 >> I'm not against using ULAs, but what do you put in DNS? Do you make = separate >> internal zones with ULAs? This is a solved problem. You can (and should, for a CPE) use = home.arpa. as an internal zone. Additionally, if you are using multicast DNS internally, which is = generally the case, you don=E2=80=99t need a zone at all=E2=80=94just = use .local. >> In the case of a static prefix, just listing public addresses is way = more >> convenient.=20 This is a real edge case=E2=80=94the way you describe this, I am fairly = sure you are talking about typing names into zone files. O(nobody) is = ever going to do this on a home network. If the name shows up in the = DNS, it=E2=80=99s because the CPE device has a way to make it show up in = the DNS. For that use case, ULAs work just fine. > Indeed. And for that reason there is no consensus that ULA should be = recommended in home networks either. I don=E2=80=99t think this is actually the case. I understand that = there is not full consensus, but I think there is rough consensus: what = I observe in terms of implementations is that everybody provides ULAs. = I understand that you are in the rough here, but I think you really are = in the rough. > =46rom what I have seen trying to make multi-homing work, I'm not sure = I would trust host stack behaviour with regards to source address = selection having link-local, ULA and global either. > (and link-local addresses really only work with applications = specifically supporting it). Any application that uses mDNS will automatically get the ULA for = on-link queries, so that=E2=80=99s not a problem in practice: if the = broadcast domain is flat, the link-local address can be used simply by = asking for IN AAAA hostname.local. > And I'd expect the ULA might change whenever you change CPE too (if = that's Ted's case), so even more complexity. Sure, but since the CPE isn=E2=80=99t going to advertise a long = lifetime, that=E2=80=99s okay. From nobody Thu Apr 9 09:36:31 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004233A0C08 for ; Thu, 9 Apr 2020 09:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdGMYi-AWaAK for ; Thu, 9 Apr 2020 09:36:28 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528343A0C03 for ; Thu, 9 Apr 2020 09:36:28 -0700 (PDT) Received: from [192.168.10.248] (dhcp217197164175.blix.com [217.197.164.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 506FE4E11BAF; Thu, 9 Apr 2020 16:36:27 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Thu, 9 Apr 2020 18:36:24 +0200 Message-Id: <52C087F6-CF16-40B5-8638-0EC4E285ECC1@employees.org> References: <6A3A994C-7A96-49AC-B44E-67EA662C8D88@fugue.com> Cc: Philip Homburg , v6ops@ietf.org In-Reply-To: <6A3A994C-7A96-49AC-B44E-67EA662C8D88@fugue.com> To: Ted Lemon X-Mailer: iPhone Mail (17E255) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 16:36:30 -0000 Ted, I take it you describe some future vision of how you would like home network= s to work. That=E2=80=99s fine. Unfortunately O(nobody) are able to operate t= hem like that now.=20 Ole > On 9 Apr 2020, at 18:01, Ted Lemon wrote: >=20 > =EF=BB=BFOn Apr 9, 2020, at 10:07 AM, otroan@employees.org wrote: >>> Note, the scenario is where I have a fixed prefix. But for technical >>> reason I'm forced to run DHCPv6 PD. So, no flash renumbering expeced. >>>=20 >>> I'm not against using ULAs, but what do you put in DNS? Do you make sepa= rate >>> internal zones with ULAs? >=20 > This is a solved problem. You can (and should, for a CPE) use home.arpa. a= s an internal zone. >=20 > Additionally, if you are using multicast DNS internally, which is generall= y the case, you don=E2=80=99t need a zone at all=E2=80=94just use .local. >=20 >>> In the case of a static prefix, just listing public addresses is way mor= e >>> convenient.=20 >=20 > This is a real edge case=E2=80=94the way you describe this, I am fairly su= re you are talking about typing names into zone files. O(nobody) is ever g= oing to do this on a home network. If the name shows up in the DNS, it=E2=80= =99s because the CPE device has a way to make it show up in the DNS. For th= at use case, ULAs work just fine. >=20 >> Indeed. And for that reason there is no consensus that ULA should be reco= mmended in home networks either. >=20 > I don=E2=80=99t think this is actually the case. I understand that there i= s not full consensus, but I think there is rough consensus: what I observe i= n terms of implementations is that everybody provides ULAs. I understand th= at you are in the rough here, but I think you really are in the rough. >=20 >> =46rom what I have seen trying to make multi-homing work, I'm not sure I w= ould trust host stack behaviour with regards to source address selection hav= ing link-local, ULA and global either. >> (and link-local addresses really only work with applications specifically= supporting it). >=20 > Any application that uses mDNS will automatically get the ULA for on-link q= ueries, so that=E2=80=99s not a problem in practice: if the broadcast domain= is flat, the link-local address can be used simply by asking for IN AAAA ho= stname.local. >=20 >> And I'd expect the ULA might change whenever you change CPE too (if that'= s Ted's case), so even more complexity. >=20 > Sure, but since the CPE isn=E2=80=99t going to advertise a long lifetime, t= hat=E2=80=99s okay. >=20 From nobody Thu Apr 9 10:23:04 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF913A0DA1 for ; Thu, 9 Apr 2020 10:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxL74fbjl_I0 for ; Thu, 9 Apr 2020 10:23:00 -0700 (PDT) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6593A0CB5 for ; Thu, 9 Apr 2020 10:22:04 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id l25so4795864qkk.3 for ; Thu, 09 Apr 2020 10:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IYSnmJxbPjpM5jFdfaQBgrckCSzM6EPEKkvmUdFciug=; b=0s6/zuH3VBdtSNbH1lBMey6ZwNitaq4eKaT6JIdFNdvpz441pXEngS6bw9dS7EGGae +bzwEElowsuokcqCP40ji/qsyBezbqYtEYNgnKdgLrx6Q/ro5V+czaQBd8m1aFk+oTok N058qYZB995W54szTKeay0cZcu57HYY+5V5bQqN+pozGTmen4Vfo1B1g73vFL5wkpyPN kWYVsUCU1Id/vyIpqBdq8Nvs3LtMc8F+36qSk4W6RMocc22GOUQ9RMKAHsjbmvaFAAYl 903JI/D29IMzq5vGGx8hPJFOI3QhFGw2XkDsF10WR1J+AvD9vTveKL1tqodlFZadPSRW mVyA== 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=IYSnmJxbPjpM5jFdfaQBgrckCSzM6EPEKkvmUdFciug=; b=pNMXYDyVLfWq7qnvNaur9BKIi2I3C3Efjxjvqmj3EdUzuLaJcCgrVrHiLhrLeJxDwV WzwaS0Ey0Dv15o3VT1d1wIEY3HA7a6FMiruRL/lvlJ8mukUTAw5t2o9jD0Cpsogk5IJd EiOCLkNKnJEWDrx+VHrNSr9jeiIX5YYNHnZpMFR6miea3nqqX007vMqskQLf2wYMmJFi TslMf0qm6E0mVSOgrNSvKjVJ2N8kIZ/ZS1ZcTTBvMmY7ICwNQZN0AIIslFmw/Tbv1GrB 0lrdphytTbKOStWTqAMTq1Yyl3zkNwIAC9ythXdaLejxytmlUlsPhnOCTjL451aaIi6E 5yIA== X-Gm-Message-State: AGi0PuYAVqWQ8FkMH/tPqtEHv7ctkXQxqU4TRM81s/VAfaHQ06QreYP3 YEJNZpS9HqWZpHGQtm2/KexkIUQc9xw= X-Google-Smtp-Source: APiQypKY3iU/DTQPOKdt4iPSZLQRSDsEH3SYlXQ3mk+9z9iGvTS3cvDh7p82JeBsfTHX+oN7zV7q+A== X-Received: by 2002:a37:7987:: with SMTP id u129mr962664qkc.312.1586452923184; Thu, 09 Apr 2020 10:22:03 -0700 (PDT) Received: from [192.168.1.241] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id d189sm12731128qkf.118.2020.04.09.10.22.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 10:22:02 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_738B0393-DFB2-42D8-BA9C-1A9320D82E41" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.6\)) Date: Thu, 9 Apr 2020 13:22:00 -0400 In-Reply-To: <52C087F6-CF16-40B5-8638-0EC4E285ECC1@employees.org> Cc: Philip Homburg , v6ops@ietf.org To: Ole Troan References: <6A3A994C-7A96-49AC-B44E-67EA662C8D88@fugue.com> <52C087F6-CF16-40B5-8638-0EC4E285ECC1@employees.org> X-Mailer: Apple Mail (2.3622.0.6) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 17:23:03 -0000 --Apple-Mail=_738B0393-DFB2-42D8-BA9C-1A9320D82E41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 9, 2020, at 12:36 PM, Ole Troan wrote: > I take it you describe some future vision of how you would like home = networks to work. That=E2=80=99s fine. Unfortunately O(nobody) are able = to operate them like that now.=20 No, with the exception of implementing RFC 6763 using DNS rather than = mDNS, everything that I described is current practice. If you have a = Mac or an iPhone and a printer, they most likely communicate using IPv6 = link-local addresses. I don=E2=80=99t know if your router at home publishes a ULA, but my Eero = mesh does, my OpenWRT routers do, and the Apple Airport Base Station I = was debugging the other day does. Anecdata, granted, but that=E2=80=99s = a pretty broad spectrum. --Apple-Mail=_738B0393-DFB2-42D8-BA9C-1A9320D82E41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Apr 9, 2020, at 12:36 PM, Ole Troan <otroan@employees.org> wrote:
I take it you describe some future vision of how you would = like home networks to work. That=E2=80=99s fine. Unfortunately O(nobody) = are able to operate them like that now. 

No, with the exception of implementing = RFC 6763 using DNS rather than mDNS, everything that I described is = current practice.  If you have a Mac or an iPhone and a printer, = they most likely communicate using IPv6 link-local addresses.

I don=E2=80=99t know if = your router at home publishes a ULA, but my Eero mesh does, my OpenWRT = routers do, and the Apple Airport Base Station I was debugging the other = day does.  Anecdata, granted, but that=E2=80=99s a pretty broad = spectrum.

= --Apple-Mail=_738B0393-DFB2-42D8-BA9C-1A9320D82E41-- From nobody Thu Apr 9 11:54:24 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997933A0C13 for ; Thu, 9 Apr 2020 11:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfOSzgql8UEM for ; Thu, 9 Apr 2020 11:54:20 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F4A3A0C11 for ; Thu, 9 Apr 2020 11:54:20 -0700 (PDT) Received: from [192.168.10.189] (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 047C34E11AEC; Thu, 9 Apr 2020 18:54:20 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-392D28B2-2C71-4F08-BAD4-E1D2DFA74D5A Content-Transfer-Encoding: 7bit From: Ole Troan Mime-Version: 1.0 (1.0) Date: Thu, 9 Apr 2020 20:54:16 +0200 Message-Id: <4572EB79-812C-40A6-A93D-A61F7E2245FA@employees.org> References: Cc: Philip Homburg , v6ops@ietf.org In-Reply-To: To: Ted Lemon X-Mailer: iPhone Mail (17E255) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 18:54:23 -0000 --Apple-Mail-392D28B2-2C71-4F08-BAD4-E1D2DFA74D5A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted, Expose the internal services in the home to the outside. Home-assistant, ssh= , xmpp server etc. That=E2=80=99s painful enough with static addresses. But if you tell me that= =E2=80=99s all plug and play then please share. And yes, this is pretty much the only end user relevant value add of IPv6, s= o we better make sure it works.=20 Cheers, Ole > On 9 Apr 2020, at 19:22, Ted Lemon wrote: >=20 > =EF=BB=BFOn Apr 9, 2020, at 12:36 PM, Ole Troan wro= te: >> I take it you describe some future vision of how you would like home netw= orks to work. That=E2=80=99s fine. Unfortunately O(nobody) are able to opera= te them like that now.=20 >=20 > No, with the exception of implementing RFC 6763 using DNS rather than mDNS= , everything that I described is current practice. If you have a Mac or an i= Phone and a printer, they most likely communicate using IPv6 link-local addr= esses. >=20 > I don=E2=80=99t know if your router at home publishes a ULA, but my Eero m= esh does, my OpenWRT routers do, and the Apple Airport Base Station I was de= bugging the other day does. Anecdata, granted, but that=E2=80=99s a pretty b= road spectrum. >=20 --Apple-Mail-392D28B2-2C71-4F08-BAD4-E1D2DFA74D5A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ted,

Expose the internal services in the home to the o= utside. Home-assistant, ssh, xmpp server etc.
That=E2=80= =99s painful enough with static addresses. But if you tell me that=E2=80=99s= all plug and play then please share.
And yes, this is= pretty much the only end user relevant value add of IPv6, so we better make= sure it works. 

Cheer= s,
Ole

On 9 Apr 2020, at 19:22, Ted Lemon <mellon@fugue.com> wrote:
<= br>
=EF=BB=BFOn Ap= r 9, 2020, at 12:36 PM, Ole Troan <otroan@employees.org> wrote:
I take it you describe some future vision= of how you would like home networks to work. That=E2=80=99s fine. Unfortuna= tely O(nobody) are able to operate them like that now. 

=
No, with the exception of implementing RFC 6763 using DNS ra= ther than mDNS, everything that I described is current practice.  If yo= u have a Mac or an iPhone and a printer, they most likely communicate using I= Pv6 link-local addresses.

I don=E2=80=99t know if your router at home publishes a ULA, but my E= ero mesh does, my OpenWRT routers do, and the Apple Airport Base Station I w= as debugging the other day does.  Anecdata, granted, but that=E2=80=99s= a pretty broad spectrum.

= --Apple-Mail-392D28B2-2C71-4F08-BAD4-E1D2DFA74D5A-- From nobody Thu Apr 9 12:04:40 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11013A0C29 for ; Thu, 9 Apr 2020 12:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Gk-9_DAWn4U for ; Thu, 9 Apr 2020 12:04:37 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542AB3A0C27 for ; Thu, 9 Apr 2020 12:04:37 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id m67so5130047qke.12 for ; Thu, 09 Apr 2020 12:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/F/DrnL5vECSE/8gkJ8VMtlUFc0hZLDvnFo1oGIM/7A=; b=Hvad+envw5cLaGsFUFD0cI7GxZ/Wumh7kVaNwTEwI7OVyArtAD8VEtrUe80B0PBb8h CuTYLkLK4eRsrArxVDk47NOjM1KvZ/4EjhRWg5VKSWXc+i1+/DCLA9Sn7xJQwvQlbAh/ OugVVZbdP3KC/xuSHl7V1PNnAuATTB1FbHShcxmkdgpIi3gm+5ug/t4Rl9UAWs5Yvwtk J0WJewV/RSENuBUtlpP3Jh+9b4IvFdlh+cI7RxiFnXWVM6pW/pG+cqXGZ0eos/s6GTSP Vy4NAU/KFpKGPscnNlurj64KUjonTblZoVkMNRQFZvRM4dPzCRjuft+xjOIuCYDVBMX5 x3ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/F/DrnL5vECSE/8gkJ8VMtlUFc0hZLDvnFo1oGIM/7A=; b=pl5YbWFhsXZauuBZqgcT00kGM5YekFIkCiGoX+azitrDY5vWqnvJ1VCuJVWmgapnnN FLPmZz/NbdpLZ3k3yqPzdgeQUhZMTa/iwZ8i+z15hB41MRbZiVdkuIgMYs0KGHgMbWsI afz2Kvt2OPJ40rMCfJgd5M/6rIpbNuS7VpzQoje30zJ+kdMksRgQD9HV2pgJjrhjeT0n 5y+xM7PxqseTIOleDAJTETXOmZVtOtDAHaqxqf9PsbKSVLAQ+z/hSqXWkX5QD/pJ7Flw WV/+cucqXxno63r0VwpieHVIWGL41RYrTXT2kPrayC3yXL8UZTZ5N76OasU5PS5s2Anq fgqQ== X-Gm-Message-State: AGi0PuZ5FPwsminv7EU8B0QLWMEFr4U0tV+7vHSn+avWq0q0yQ5OmJ9R ZV1jnmU95P9wTH6dj9UKjomLi3dOftg= X-Google-Smtp-Source: APiQypI7wyCzk76sLnU8xow3W16PJBrDVEakXyS6+qC7I3k5xNlfg59hldxm1dO4r6sbIHI8SnscYQ== X-Received: by 2002:a05:620a:670:: with SMTP id a16mr287733qkh.467.1586459076218; Thu, 09 Apr 2020 12:04:36 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id e17sm21516737qtw.1.2020.04.09.12.04.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 12:04:35 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_167CA2CA-BA03-4A8F-8036-05E5D527873C" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.6\)) Date: Thu, 9 Apr 2020 15:04:33 -0400 In-Reply-To: <4572EB79-812C-40A6-A93D-A61F7E2245FA@employees.org> Cc: Philip Homburg , v6ops@ietf.org To: Ole Troan References: <4572EB79-812C-40A6-A93D-A61F7E2245FA@employees.org> X-Mailer: Apple Mail (2.3622.0.6) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2020 19:04:39 -0000 --Apple-Mail=_167CA2CA-BA03-4A8F-8036-05E5D527873C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 9, 2020, at 2:54 PM, Ole Troan wrote: > Expose the internal services in the home to the outside. = Home-assistant, ssh, xmpp server etc. > That=E2=80=99s painful enough with static addresses. But if you tell = me that=E2=80=99s all plug and play then please share. > And yes, this is pretty much the only end user relevant value add of = IPv6, so we better make sure it works.=20 This is a pretty rare use case. However, if you want to advertise a = home service for global reachability, of course you have to use a GUA. = I would hope that you don=E2=80=99t use a long TTL if your ISP doesn=E2=80= =99t guarantee you a static address. Personally, my solution to this is = to have a local DNS server and change the zone file whenever my public = IPv4 address or GUA prefix changes. So in a sense this is a solved = problem, but I agree that we don=E2=80=99t have a good automation = solution for it, and I don=E2=80=99t believe I ever claimed otherwise. --Apple-Mail=_167CA2CA-BA03-4A8F-8036-05E5D527873C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Apr 9, 2020, at 2:54 PM, Ole Troan <otroan@employees.org> wrote:
Expose = the internal services in the home to the outside. Home-assistant, ssh, = xmpp server etc.
That=E2=80=99s painful enough with = static addresses. But if you tell me that=E2=80=99s all plug and play = then please share.
And yes, this is pretty much the only = end user relevant value add of IPv6, so we better make sure it = works. 

This is a pretty rare use case.  However, if you want to = advertise a home service for global reachability, of course you have to = use a GUA.  I would hope that you don=E2=80=99t use a long TTL if = your ISP doesn=E2=80=99t guarantee you a static address. =  Personally, my solution to this is to have a local DNS server and = change the zone file whenever my public IPv4 address or GUA prefix = changes.  So in a sense this is a solved problem, but I agree that = we don=E2=80=99t have a good automation solution for it, and I don=E2=80=99= t believe I ever claimed otherwise.

= --Apple-Mail=_167CA2CA-BA03-4A8F-8036-05E5D527873C-- From nobody Thu Apr 9 19:19:37 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23FF3A1954 for ; Thu, 9 Apr 2020 19:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy4PULvUtbCB for ; Thu, 9 Apr 2020 19:19:32 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9873C3A1953 for ; Thu, 9 Apr 2020 19:19:32 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 1000D802C8; Fri, 10 Apr 2020 04:19:27 +0200 (CEST) To: Ted Lemon , Ole Troan Cc: v6ops@ietf.org References: <4572EB79-812C-40A6-A93D-A61F7E2245FA@employees.org> From: Fernando Gont Message-ID: <72f539c1-ed51-551b-069d-2063ec6527f0@si6networks.com> Date: Thu, 9 Apr 2020 22:22:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 02:19:35 -0000 On 9/4/20 16:04, Ted Lemon wrote: > On Apr 9, 2020, at 2:54 PM, Ole Troan > wrote: >> Expose the internal services in the home to the outside. >> Home-assistant, ssh, xmpp server etc. >> That’s painful enough with static addresses. But if you tell me that’s >> all plug and play then please share. >> And yes, this is pretty much the only end user relevant value add of >> IPv6, so we better make sure it works. > > This is a pretty rare use case.  However, if you want to advertise a > home service for global reachability, of course you have to use a GUA. >  I would hope that you don’t use a long TTL if your ISP doesn’t > guarantee you a static address.  Personally, my solution to this is to > have a local DNS server and change the zone file whenever my public IPv4 > address or GUA prefix changes. Indeed. And you use short TTLs, because, otherwise, if your address changes, you'll keep stale information in DNS caches for a long time. Similar idea of what we have been discussing here. 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 Apr 9 19:26:43 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5527B3A196C for ; Thu, 9 Apr 2020 19:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSzzvuI2KU_c for ; Thu, 9 Apr 2020 19:26:40 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D76C3A1967 for ; Thu, 9 Apr 2020 19:26:40 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03A2QbBd1322625 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Apr 2020 19:26:39 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03A2QbBd1322625 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586485599; bh=7X0q3TUFSHv3/Y3ZOx+dKe8ocznK/d0cmxwtLpWDxAQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=n+lUdax1po8cIagig73PnbyvXK+r0MSTneyIzJEFmZ5EAxzsDmFPfqAVhsymAsbBp dDGV0QRjkyjGicjZVnudZTe07FGWbdukeuQogRJX6IeAhKPx2SoQFDzb4sXA4y7ZHO 238l2QTfgBtfkHyvmsgNFsHtEd96CMWbci21I+ss= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: Date: Thu, 9 Apr 2020 19:26:36 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <94021F65-ADBC-43E8-997C-4F0FD25EB5F0@delong.com> References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> <5079EE4E-D48F-4C8A-ABBC-FB71DDFFC003@delong.com> To: Philip Homburg X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Thu, 09 Apr 2020 19:26:39 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 02:26:42 -0000 > On Apr 9, 2020, at 05:48 , Philip Homburg = wrote: >=20 >>> Just like you can have static IPv4 addresses and still hand them out = using >>> DHCPv4. >>=20 >> Nope. >>=20 >> Theyre fixed dynamic addresses at that point, not static addresses. >=20 > Call it fixed dynamic address. What does that even mean? It is dynamic > but never changing? It is delegated via a dynamic mechanism, but it is not dynamically = assigned. It is fixed in its assignment, yet dynamic in its delegation. Thus, on the receiving end, it is still a dynamic address as the serving = end may decide to change it at the end of any given lease period. If you control both the client and the server, then sure, that may never = occur, but the point is that according to the specs and the protocols, it can. >> Similarly, you can receive a fixed dynamic prefix via DHCP-PD, but >> its still being issued to you dynamically and it wont keep working >> if you dont renew the lease. >=20 > That very much depends on the situation. In many cases, you can keep = using=20 > a 'fixed dynamic' IPv4 address without running a DHCP client. In other > cases it may not work. You may get away with this, but it=E2=80=99s a time bomb. Eventually, = someone is likely to update the DHCP server and depending on whether they remember (or know) the the host in that particular fixed address clause isn=E2=80=99= t actually doing DHCP, life could get interesting in a number of ways. Really bad administrative practice as far as I=E2=80=99m concerned. If you want to = have hosts with static addresses, then put them in a section of the network = that=E2=80=99s not in the DHCP scope. > But the issue is not whether external communication works or not. When = the > router is down, there is no external communication, whether the prefix = is > still valid or not. I never said that the issue was external communication. If your internet connection goes down long enough to time out your DHCP lease, I=E2=80=99d think that renumbering your LAN would be among the least of your concerns. > However, that does not mean that local connections should break. Nor did I say that they should. In general, an ISP using DHCP to hand = out fixed prefixes should be choosing pretty long lease times (on the order of weeks if not a month or more, ideally something approximating the length of time for which you=E2=80=99ve paid). In such a case, your local connections won=E2=80=99t break for many days = after you=E2=80=99ve lost your internet connection. > The only thing I'm asking it to allow the operator to configure things > differently based on the local situation. Not that it should be the = default > or happen automatically. Yeah, I=E2=80=99m not convinced that benefiting your corner case exceeds = the likely harm when $END_USER who doesn=E2=80=99t know what those timers really mean starts playing games. Owen From nobody Thu Apr 9 19:36:55 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD39C3A1996 for ; Thu, 9 Apr 2020 19:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 uzjPB_tYZIzm for ; Thu, 9 Apr 2020 19:36:52 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id AF2F03A1993 for ; Thu, 9 Apr 2020 19:36:42 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03A2abga1325301 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Apr 2020 19:36:37 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03A2abga1325301 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586486197; bh=ouBK/KkFLNC9mlc18X3uMKvfHYw6rNYoNNX/+i2NB20=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=f24Dfyh2oUiyfVy7DFs7gCek9S7W76BwOP0ZeISajHLAkF5kgX00PnkUDeW4ztR27 X6IaW2X2Gqpr8MymZwme3eHBWwlejJNLiPBD8OuTb7BNV2SUGXkeUy6FwhuJ5/+Qr2 cm/jE17Xp7kMbhVNaHGfBwy5YdKqqnChY5YPe06E= From: Owen DeLong Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_48B86940-E7E4-41D0-98B6-3D27F6EC8BDD" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 9 Apr 2020 19:36:37 -0700 In-Reply-To: <6A3A994C-7A96-49AC-B44E-67EA662C8D88@fugue.com> Cc: Ole Troan , v6ops@ietf.org To: Ted Lemon References: <2B9CCF8A-87FE-4C5B-96FD-B8C5FE42F9F8@fugue.com> <2E01C362-29E0-4AB3-84CA-E63D2D734F5F@employees.org> <6A3A994C-7A96-49AC-B44E-67EA662C8D88@fugue.com> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Thu, 09 Apr 2020 19:36:37 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 02:36:54 -0000 --Apple-Mail=_48B86940-E7E4-41D0-98B6-3D27F6EC8BDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 9, 2020, at 09:00 , Ted Lemon wrote: >=20 > On Apr 9, 2020, at 10:07 AM, otroan@employees.org wrote: >> Indeed. And for that reason there is no consensus that ULA should be = recommended in home networks either. >=20 > I don=E2=80=99t think this is actually the case. I understand that = there is not full consensus, but I think there is rough consensus: what = I observe in terms of implementations is that everybody provides ULAs. = I understand that you are in the rough here, but I think you really are = in the rough. Actually, while I think that Philip is pushing an edge case, I agree = with him about the lack of consensus for ULA in the home. Personally, IMHO, ULA is one of those things we=E2=80=99d be better off = without. >=20 >> =46rom what I have seen trying to make multi-homing work, I'm not = sure I would trust host stack behaviour with regards to source address = selection having link-local, ULA and global either. >> (and link-local addresses really only work with applications = specifically supporting it). >=20 > Any application that uses mDNS will automatically get the ULA for = on-link queries, so that=E2=80=99s not a problem in practice: if the = broadcast domain is flat, the link-local address can be used simply by = asking for IN AAAA hostname.local. Which is it? We=E2=80=99ll get the ULA or the Link Local? Your own = statement displays the obvious probably confusion that will result when = one combines mDNS with GUA, ULA, and Link Local addresses. This would seem to argue that the GUA will be used: from the host raspberrypi-4.local on my network: 2: eth0: mtu 1500 qdisc mq state UP = group default qlen 1000 link/ether dc:a6:32:63:cb:d3 brd ff:ff:ff:ff:ff:ff inet 192.159.10.225/24 brd 10.0.0.255 scope global dynamic = noprefixroute eth0 valid_lft 2533sec preferred_lft 2083sec inet6 fda6:abcd:ef01:9a32::5/64 scope global=20 valid_lft forever preferred_lft forever inet6 2620:0:930:0:f05a:a7e6:4110:513/64 scope global dynamic = mngtmpaddr noprefixroute=20 valid_lft 2591751sec preferred_lft 604551sec inet6 fe80::c575:864d:8b77:25bf/64 scope link=20 valid_lft forever preferred_lft forever =46rom an adjacent iMac on the same network: (106) ~ % ping6 raspberrypi-4.local 2020/04/09 = 19:32:48 PING6(56=3D40+8+8 bytes) 2620:0:930::200:5 --> = 2620::930:0:f05a:a7e6:4110:513 16 bytes from 2620::930:0:f05a:a7e6:4110:513, icmp_seq=3D0 hlim=3D64 = time=3D0.307 ms 16 bytes from 2620::930:0:f05a:a7e6:4110:513, icmp_seq=3D1 hlim=3D64 = time=3D0.799 ms ^C --- raspberrypi-4.local ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev =3D 0.307/0.553/0.799/0.246 ms Owen --Apple-Mail=_48B86940-E7E4-41D0-98B6-3D27F6EC8BDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 9, 2020, at 09:00 , Ted Lemon <mellon@fugue.com> = wrote:

On Apr 9, 2020, at 10:07 AM, otroan@employees.org = wrote:
Indeed. And = for that reason there is no consensus that ULA should be recommended in = home networks either.

I = don=E2=80=99t think this is actually the case.  I understand that = there is not full consensus, but I think there is rough consensus: what = I observe in terms of implementations is that everybody provides ULAs. =  I understand that you are in the rough here, but I think you = really are in the rough.

Actually, while I think that Philip is pushing an edge = case, I agree with him about the lack of consensus for ULA in the = home.

Personally, IMHO, ULA is one = of those things we=E2=80=99d be better off without.


=46rom = what I have seen trying to make multi-homing work, I'm not sure I would = trust host stack behaviour with regards to source address selection = having link-local, ULA and global either.
(and link-local = addresses really only work with applications specifically supporting = it).

Any application that uses = mDNS will automatically get the ULA for on-link queries, so that=E2=80=99s= not a problem in practice: if the broadcast domain is flat, the = link-local address can be used simply by asking for IN AAAA = hostname.local.

Which is it? We=E2=80=99ll get the ULA or the Link = Local? Your own statement displays the obvious probably confusion that = will result when one combines mDNS with GUA, ULA, and Link Local = addresses.

This would seem to argue = that the GUA will be used:

from the = host raspberrypi-4.local on my network:
2: eth0: = <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group = default qlen 1000
    link/ether dc:a6:32:63:cb:d3 brd = ff:ff:ff:ff:ff:ff
    inet 192.159.10.225/24 brd 10.0.0.255 scope = global dynamic noprefixroute eth0
       valid_lft = 2533sec preferred_lft 2083sec
    inet6 = fda6:abcd:ef01:9a32::5/64 scope global 
       valid_lft forever preferred_lft = forever
  =   inet6 2620:0:930:0:f05a:a7e6:4110:513/64 scope global dynamic = mngtmpaddr noprefixroute 
       valid_lft = 2591751sec preferred_lft 604551sec
    inet6 = fe80::c575:864d:8b77:25bf/64 scope link 
       valid_lft forever preferred_lft = forever

=46rom an adjacent iMac on the same network:
(106) ~ = % ping6 raspberrypi-4.local            =             2020/04/09 = 19:32:48
PING6(56=3D40+8+8 bytes) 2620:0:930::200:5 --> = 2620::930:0:f05a:a7e6:4110:513
16 bytes from = 2620::930:0:f05a:a7e6:4110:513, icmp_seq=3D0 hlim=3D64 time=3D0.307 = ms
16 = bytes from 2620::930:0:f05a:a7e6:4110:513, icmp_seq=3D1 hlim=3D64 = time=3D0.799 ms
^C
--- raspberrypi-4.local ping6 statistics ---
2 = packets transmitted, 2 packets received, 0.0% packet = loss
round-trip min/avg/max/std-dev =3D 0.307/0.553/0.799/0.246 = ms

Owen

= --Apple-Mail=_48B86940-E7E4-41D0-98B6-3D27F6EC8BDD-- From nobody Thu Apr 9 19:38:42 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F014D3A19A4 for ; Thu, 9 Apr 2020 19:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 QKXfEdMIAbUq for ; Thu, 9 Apr 2020 19:38:39 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BA9003A1999 for ; Thu, 9 Apr 2020 19:38:39 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03A2cYD11325714 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Apr 2020 19:38:34 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03A2cYD11325714 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586486314; bh=mXe/j0fsXZ+RL+K5rRE1oBbMrAkErWDsutv9/wyDBYc=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=ML/LI4zLxVRNKN2c3Vp3UdbYc+FxzVGDWU3jnnz0earuW8Ia8G7sA0RlpkOWE/zzD Yt1r5LPU4QzKDz5BhIj/9aeX1DQpBUPEeVQ2VkUsFLDFtuA6i5vXn2J5vdEL6s1m09 wyYwpbBhGCcNNGYNDIG7V7VLhD7nNWkVmHDI9sx8= From: Owen DeLong Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8FE03334-EDBA-4EFE-9EF5-AC3B3132AD08" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 9 Apr 2020 19:38:33 -0700 In-Reply-To: Cc: Ole Troan , v6ops@ietf.org To: Ted Lemon References: <6A3A994C-7A96-49AC-B44E-67EA662C8D88@fugue.com> <52C087F6-CF16-40B5-8638-0EC4E285ECC1@employees.org> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Thu, 09 Apr 2020 19:38:34 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 02:38:41 -0000 --Apple-Mail=_8FE03334-EDBA-4EFE-9EF5-AC3B3132AD08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 9, 2020, at 10:22 , Ted Lemon wrote: >=20 > On Apr 9, 2020, at 12:36 PM, Ole Troan > wrote: >> I take it you describe some future vision of how you would like home = networks to work. That=E2=80=99s fine. Unfortunately O(nobody) are able = to operate them like that now.=20 >=20 > No, with the exception of implementing RFC 6763 using DNS rather than = mDNS, everything that I described is current practice. If you have a = Mac or an iPhone and a printer, they most likely communicate using IPv6 = link-local addresses. Nope=E2=80=A6 They=E2=80=99re all using GUA. > I don=E2=80=99t know if your router at home publishes a ULA, but my = Eero mesh does, my OpenWRT routers do, and the Apple Airport Base = Station I was debugging the other day does. Anecdata, granted, but = that=E2=80=99s a pretty broad spectrum. Mine does not=E2=80=A6 I had to add the ULA address to the hosts in my = previous message just to do that test. It=E2=80=99s since been removed. Normally, I don=E2=80=99t want the additional headaches of ULA which = offers zero benefit in my environment. None of my Apple Airports ever issued ULAs. Owen --Apple-Mail=_8FE03334-EDBA-4EFE-9EF5-AC3B3132AD08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 9, 2020, at 10:22 , Ted Lemon <mellon@fugue.com> = wrote:

On Apr 9, 2020, at = 12:36 PM, Ole Troan <otroan@employees.org> wrote:
I take it you describe some future vision of how you would = like home networks to work. That=E2=80=99s fine. Unfortunately O(nobody) = are able to operate them like that now. 

No, with the exception of implementing = RFC 6763 using DNS rather than mDNS, everything that I described is = current practice.  If you have a Mac or an iPhone and a printer, = they most likely communicate using IPv6 link-local = addresses.

Nope=E2= =80=A6 They=E2=80=99re all using GUA.

I = don=E2=80=99t know if your router at home publishes a ULA, but my Eero = mesh does, my OpenWRT routers do, and the Apple Airport Base Station I = was debugging the other day does.  Anecdata, granted, but that=E2=80=99= s a pretty broad spectrum.

Mine does not=E2=80=A6 I had to add the ULA address to = the hosts in my previous message just to do that test. It=E2=80=99s = since been removed.

Normally, I = don=E2=80=99t want the additional headaches of ULA which offers zero = benefit in my environment.

None of = my Apple Airports ever issued ULAs.

Owen

= --Apple-Mail=_8FE03334-EDBA-4EFE-9EF5-AC3B3132AD08-- From nobody Fri Apr 10 00:26:22 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E133A08DD for ; Fri, 10 Apr 2020 00:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_TEMPERROR=0.01] 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 0A2BOuON9pma for ; Fri, 10 Apr 2020 00:26:01 -0700 (PDT) Received: from mail.consulintel.com (mail.consulintel.com [213.0.69.132]) by ietfa.amsl.com (Postfix) with ESMTP id C42F33A08C9 for ; Fri, 10 Apr 2020 00:25:39 -0700 (PDT) X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.com, Fri, 10 Apr 2020 09:17:42 +0200 Received: from mail.consulintel.es ([2001:470:1f09:495::5]) by mail.consulintel.com ([2001:470:1f1d:275::250]) (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v16.5.2) with ESMTPS id md50001042376.msg for ; Fri, 10 Apr 2020 09:17:40 +0200 X-Spam-Processed: mail.consulintel.com, Fri, 10 Apr 2020 09:17:40 +0200 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 2001:470:1f09:495::5 X-MDHelo: mail.consulintel.es X-MDArrival-Date: Fri, 10 Apr 2020 09:17:40 +0200 X-Return-Path: prvs=1369bbbead=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1586503016; x=1587107816; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=5fAFgkcA MkcNqhiuIIVAPUbUZCC2+ORoGcfdowO7Czk=; b=orf+eZ42+0seYlptwYRuWlFe GHUwWVMwMEY4oB2Zib22vyER2j1BNb3QXI7MItN0kWPjDpfF6ZW0wLVmz5EE0gaq j4vYM4v31gfBvIqn6X4d5cFzaOAkJhWc+QN9pqHsd9cAs0XPNixSicAEAToXtq6Y TsfU+Qs1ucrAJVs+GgQ= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 10 Apr 2020 09:16:56 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 10 Apr 2020 09:16:54 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000120828.msg for ; Fri, 10 Apr 2020 09:16:53 +0200 User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Fri, 10 Apr 2020 09:16:48 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <4BB07A18-CB6F-4000-8152-6B430A13CD06@consulintel.es> Thread-Topic: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> <5079EE4E-D48F-4C8A-ABBC-FB71DDFFC003@delong.com> <94021F65-ADBC-43E8-997C-4F0FD25EB5F0@delong.com> In-Reply-To: <94021F65-ADBC-43E8-997C-4F0FD25EB5F0@delong.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 07:26:21 -0000 When working in RIPE690 (https://www.ripe.net/publications/docs/ripe-690), = we found that "persistent/non-persistent addresses" is a good way to avoid = confusions with dynamic mechanism vs dynamically assigned addresses. When I= 've presented this document to different audiences, they also agreed that i= t is much clearer. So, I think it will be good to be consistent by keeping using that terminol= ogy, and help to avoid those confusions. In fact, it will be also good to i= nclude a non-normative reference to this document. =20 Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 10/4/20 4:27, "v6ops en nombre de Owen DeLong" escribi=C3=B3: =20 =20 > On Apr 9, 2020, at 05:48 , Philip Homburg wrote: >=20 >>> Just like you can have static IPv4 addresses and still hand them ou= t using >>> DHCPv4. >>=20 >> Nope. >>=20 >> Theyre fixed dynamic addresses at that point, not static addresses. >=20 > Call it fixed dynamic address. What does that even mean? It is dynami= c > but never changing? =20 It is delegated via a dynamic mechanism, but it is not dynamically assi= gned. It is fixed in its assignment, yet dynamic in its delegation. =20 Thus, on the receiving end, it is still a dynamic address as the servin= g end may decide to change it at the end of any given lease period. =20 If you control both the client and the server, then sure, that may neve= r occur, but the point is that according to the specs and the protocols, it can. =20 >> Similarly, you can receive a fixed dynamic prefix via DHCP-PD, but >> its still being issued to you dynamically and it wont keep working >> if you dont renew the lease. >=20 > That very much depends on the situation. In many cases, you can keep = using=20 > a 'fixed dynamic' IPv4 address without running a DHCP client. In othe= r > cases it may not work. =20 You may get away with this, but it=E2=80=99s a time bomb. Eventually, s= omeone is likely to update the DHCP server and depending on whether they remember (or know) the the host in that particular fixed address clause isn=E2= =80=99t actually doing DHCP, life could get interesting in a number of ways. Really bad administrative practice as far as I=E2=80=99m concerned. If you want to= have hosts with static addresses, then put them in a section of the network that= =E2=80=99s not in the DHCP scope. =20 > But the issue is not whether external communication works or not. Whe= n the > router is down, there is no external communication, whether the prefi= x is > still valid or not. =20 I never said that the issue was external communication. If your interne= t connection goes down long enough to time out your DHCP lease, I=E2=80= =99d think that renumbering your LAN would be among the least of your concerns. =20 > However, that does not mean that local connections should break. =20 Nor did I say that they should. In general, an ISP using DHCP to hand o= ut fixed prefixes should be choosing pretty long lease times (on the order of weeks if not a month or more, ideally something approximating the length of time for which you=E2=80=99ve paid). =20 In such a case, your local connections won=E2=80=99t break for many day= s after you=E2=80=99ve lost your internet connection. =20 > The only thing I'm asking it to allow the operator to configure thing= s > differently based on the local situation. Not that it should be the d= efault > or happen automatically. =20 Yeah, I=E2=80=99m not convinced that benefiting your corner case exceed= s the likely harm when $END_USER who doesn=E2=80=99t know what those timers really mean starts playing games. =20 Owen =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.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 Fri Apr 10 00:32:24 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F223A1915 for ; Fri, 10 Apr 2020 00:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7mJzDEFZfsh for ; Fri, 10 Apr 2020 00:32:18 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483FA3A0C6C for ; Fri, 10 Apr 2020 00:29:46 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3A9D74126B for ; Fri, 10 Apr 2020 09:29:03 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 0C3E7406BA; Fri, 10 Apr 2020 09:29:03 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id F18D626939; Fri, 10 Apr 2020 09:29:02 +0200 (CEST) Date: Fri, 10 Apr 2020 09:29:02 +0200 From: Gert Doering To: Ole Troan Cc: Ted Lemon , v6ops@ietf.org Message-ID: <20200410072902.GD50230@Space.Net> References: <4572EB79-812C-40A6-A93D-A61F7E2245FA@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4572EB79-812C-40A6-A93D-A61F7E2245FA@employees.org> X-NCC-RegID: de.space User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 07:32:21 -0000 HI, On Thu, Apr 09, 2020 at 08:54:16PM +0200, Ole Troan wrote: > Expose the internal services in the home to the outside. Home-assistant, ssh, xmpp server etc. That's about O(nobody). 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 Fri Apr 10 01:10:35 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A271F3A196E for ; Fri, 10 Apr 2020 01:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1-0SfO2vZcf for ; Fri, 10 Apr 2020 01:10:32 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3898D3A0D9E for ; Fri, 10 Apr 2020 01:10:31 -0700 (PDT) Received: from [IPv6:2a01:79d:53aa:d30:302e:ed6a:791f:1f08] (unknown [IPv6:2a01:79d:53aa:d30:302e:ed6a:791f:1f08]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 677734E11B46; Fri, 10 Apr 2020 08:10:30 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Fri, 10 Apr 2020 10:10:27 +0200 Message-Id: <95DDC987-5A36-4EEF-9C0D-CB0DE782BCF9@employees.org> References: <20200410072902.GD50230@Space.Net> Cc: Ted Lemon , v6ops@ietf.org In-Reply-To: <20200410072902.GD50230@Space.Net> To: Gert Doering X-Mailer: iPhone Mail (17E255) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 08:10:34 -0000 > On 10 Apr 2020, at 09:29, Gert Doering wrote: >=20 > =EF=BB=BFHI, >=20 >> On Thu, Apr 09, 2020 at 08:54:16PM +0200, Ole Troan wrote: >> Expose the internal services in the home to the outside. Home-assistant, s= sh, xmpp server etc. >=20 > That's about O(nobody). And the only value proposition IPv6 had to offer.=20 With end users forced into ephemeral addressing the complexity of an end to e= nd IPv6 Internet is on par with IPv4. If that reasoning is correct slaac-renum is the last nail in the coffin.=20 Ole >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael E= mmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Apr 10 01:23:08 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0A03A19BF for ; Fri, 10 Apr 2020 01:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 xEYqW2tE53DI for ; Fri, 10 Apr 2020 01:23:04 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600FE3A19BE for ; Fri, 10 Apr 2020 01:23:04 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 10CDB43936 for ; Fri, 10 Apr 2020 10:23:02 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 9B41443934; Fri, 10 Apr 2020 10:23:01 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 8C4A52B73D; Fri, 10 Apr 2020 10:23:01 +0200 (CEST) Date: Fri, 10 Apr 2020 10:23:01 +0200 From: Gert Doering To: Ole Troan Cc: Gert Doering , Ted Lemon , v6ops@ietf.org Message-ID: <20200410082301.GF50230@Space.Net> References: <20200410072902.GD50230@Space.Net> <95DDC987-5A36-4EEF-9C0D-CB0DE782BCF9@employees.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="g+hKDrowYPToEhij" Content-Disposition: inline In-Reply-To: <95DDC987-5A36-4EEF-9C0D-CB0DE782BCF9@employees.org> X-NCC-RegID: de.space User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 08:23:06 -0000 --g+hKDrowYPToEhij Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Apr 10, 2020 at 10:10:27AM +0200, Ole Troan wrote: > > On 10 Apr 2020, at 09:29, Gert Doering wrote: > >=20 > >> On Thu, Apr 09, 2020 at 08:54:16PM +0200, Ole Troan wrote: > >> Expose the internal services in the home to the outside. Home-assistan= t, ssh, xmpp server etc. > >=20 > > That's about O(nobody). >=20 > And the only value proposition IPv6 had to offer.=20 "You can configure DNS entries to point at hosts in your home"? Really? (I thought "have enough address space so that nobody is forced to hide behind a NAT if they do not want to" was the selling argument) > With end users forced into ephemeral addressing the complexity of an end = to end IPv6 Internet is on par with IPv4. "Services in the home" for O(99%) never had any reasonable chance to fly, because normal end users just don't do that. For the rest, the "WE MUST HAVE A FIREWALL IN CPEs!" discussion killed the remaining intentions. For O(99.9999%), figuring out - if they are not finding a random cloud offering much more convenient anyway - how to *understand* what they need to change in their CPE, and then find out how to *do* it, is fairly orthogonal to what their desires are in life. > If that reasoning is correct slaac-renum is the last nail in the coffin.= =20 Yeah, the IETF did a good job in ensuring IPv6 wasn't deployed in=20 reasonable ways in reasonable time, but I'm not going to rant about that today (it's in the v6ops archives already). 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 --g+hKDrowYPToEhij Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl6QLOIACgkQ31bAZeTO f8Vgiw//VGBq4y06PLHmphiQMjhV8LlNVsfwiaHU8+Aa97CpnL64HHoW7AyDBb6V B6x9My0LkDCrk/eGbVyqnnvYLyh3dqid6tJ9gMzkJO6Z3y9jtLgdXV/fZ6z6SYT2 JprCGuAAwbevcQ2uc2tYj211Eyxf5AdKTSQfKRlfuVyhGmEq7jasXSBZuTUkKzRR fhBXxrN28tkJy+Wp4g2OHRn8bQA2vQBm9CAhqM63AHWDMvkbQRiAAlt2NFeWkZxb 3IDA5BPsZCNJCP3ubzNGsC/AAnWAWrvqchI8jDrx21sGCISKZZwC7STxaz0zSDim lxH8tz/lIUI5+LO5rfdONvnFSGXMTMVoKD5M1UQw0oG6AwkE62BskSfZWcM+vdYV LjHKDLQ3vGSIRwHSh+/nDGU7vasUrgqNOZeSelKRU6qqm9YR1V6psn5+xMS4DWBd gksd9hcNQe+IT/TBx232Mn6XUt0u5nmR7j901LXi2UWAWhpyB3WF4tGb3qbX+2Y1 iYU7THn4ELvJwlk5IEXZbAkqcKsGGh91yW7jxlMvd9YZM95aUZyHI3HFFRxn4ut2 uJ77jLuawc9cm52AYkYOygYieUVcoaCWViS5McPmBkExXlQzwCrP6YqDpUPSirFB 09aw5LklThcvhLV+swTXSkkzECjL6Upla6siugBtVZEQBMoWCQc= =ZCY4 -----END PGP SIGNATURE----- --g+hKDrowYPToEhij-- From nobody Fri Apr 10 05:11:35 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728553A07C3 for ; Fri, 10 Apr 2020 05:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjleiLLVecwt for ; Fri, 10 Apr 2020 05:11:32 -0700 (PDT) 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 90D583A07BD for ; Fri, 10 Apr 2020 05:11:32 -0700 (PDT) Received: by mail-qk1-x742.google.com with SMTP id i186so1912289qke.1 for ; Fri, 10 Apr 2020 05:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=RxWF0RVIixoJAU6yTeemUu41+n5E3Jys129a+Z+gP7M=; b=cWdO40bTXsjeH88SBDcXGmeckKDaseSxGLVfyTpzvmK8NwG4j0OZXJpmolru5/DLlj qQhAFwFgPUG0q/6ycstb3nlvq6kx37Y4vTt1hV3aESG0PjqdWyehmjyvngXvZQPPSyxb amnhkTUZFlgV0AS1YGWVhLRhp1JdXxFkmh/0LLlXR7Ohk1fsUg1mZWQHa8c2d5nuHrNs kapvt6kbLQ3hTLhM7Mz+24YkcyZFXiL8npWnt1C/dnIWvmz5QsjG3uhhRPW14EUAnCjw 0Ug91pHCWvAf/VxEI95vMgHYAPt7f6O1vos6XZVjO/640JkIWuOzJU4QhgKdUjgLN4T/ YtQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=RxWF0RVIixoJAU6yTeemUu41+n5E3Jys129a+Z+gP7M=; b=ioMQ5SVcPKbL0m9g1QFbDJjn9A1sxQDo5T8vE415UEA/PT9YZU7betQMMsICTyYXUi Q6/AnRmTbm5rw+vtuiuqprShhJRGTwi6XQgeyhD5Tvna3jgTkrqSXL6ilo00Wwaf3/JG vwEbpN4K6q1Emvfzl9IH+BJ0shl8Tz1mrG58O5Pssv6NTNTOuO0IvkJaOI3FjR1HIe6O xHQIDreGJpEKl+8QSV2wzwwle3a7dR269ZsCquxG5rzn4qcs6uWPBfElA1lVoIUv9A34 nLQD1IVs8WrZYxwMphtzGMyHRua/k07MAG30tU/bI9ABztV28BWP/ZnCWj6sLbmHj8tA poGw== X-Gm-Message-State: AGi0PuZnFxVfFIulGmQ2JOH2UhrAgJUlRYbxf6IpcjuES3iIsJM4RLXC j//h9TTYDgRQptYVJgOPKVaJtAVzQmY= X-Google-Smtp-Source: APiQypJanA7LMj37gWf9PpbnQDlrrd9lMCLLWFiH2QMEpK4TSVnDdg60jriI1Z+zYUoM7UkiC26QgA== X-Received: by 2002:a37:e312:: with SMTP id y18mr3640328qki.243.1586520690870; Fri, 10 Apr 2020 05:11:30 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:890b:277e:772f:1240? ([2601:18b:300:36ee:890b:277e:772f:1240]) by smtp.gmail.com with ESMTPSA id v75sm1462530qkb.22.2020.04.10.05.11.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Apr 2020 05:11:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Fri, 10 Apr 2020 08:11:29 -0400 Message-Id: <46316DF6-5EB5-4D0C-B3B2-27DA1ED400FF@fugue.com> References: <95DDC987-5A36-4EEF-9C0D-CB0DE782BCF9@employees.org> Cc: Gert Doering , v6ops@ietf.org In-Reply-To: <95DDC987-5A36-4EEF-9C0D-CB0DE782BCF9@employees.org> To: Ole Troan X-Mailer: iPad Mail (17E255) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 12:11:35 -0000 On Apr 10, 2020, at 4:10 AM, Ole Troan wrote: >>>> On Thu, Apr 09, 2020 at 08:54:16PM +0200, Ole Troan wrote: >>> Expose the internal services in the home to the outside. Home-assistant,= ssh, xmpp server etc. >>=20 >> That's about O(nobody). >=20 > And the only value proposition IPv6 had to offer.=20 > With end users forced into ephemeral addressing the complexity of an end t= o end IPv6 Internet is on par with IPv4. >=20 > If that reasoning is correct slaac-renum is the last nail in the coffin.=20= That is hardly the only value proposition that favors IPv6. And nobody is s= aying that that value proposition isn=E2=80=99t valid. We=E2=80=99re saying t= hat it=E2=80=99s too hard right now, and so nobody is using it. We have succ= esses with IPv6, but we haven=E2=80=99t completely specified the solution sp= ace. For IPv6 to work the way you wish it to, which I also want, we still need mo= re work. We need a way for home networks to automatically publish names in t= he DNS. We need a way for home networks to not publish names in the DNS that= shouldn=E2=80=99t be. We actually have an example of the former: the DNSS= D Discovery Proxy, which is in AUTH48 at present, and for which I=E2=80=99ve= done an implementation that runs on Linux and Mac (and probably would run o= n Windows with some tweaking). The problem with the discovery proxy is that if you use it to publish names g= lobally, it will publish everything that=E2=80=99s visible locally, and that= =E2=80=99s not what we want. Also, it relies on mDNS, which is not ideal, b= ut does work. So this is incremental progress toward the goal that you are describing. As Jordi said, the goal that we=E2=80=99re talking about here is not to elim= inate stable addresses. But stable addresses solve a specific problem, not e= very problem. When we /want/ stable addresses in a certain situation, we als= o need to deal with the case where we don=E2=80=99t get them. E..g., if my I= SP won=E2=80=99t let me have a stable address, one way to handle that is to u= se TTLs that are short enough that when the ISP forces an address change, th= e DNS is updated quickly and reachability is not lost, even if persistent co= nnectivity is broken. You can=E2=80=99t force universal deployment of stable end-to-end connectivi= ty by refusing to handle the cases where you don=E2=80=99t get it. There are= legitimate cases where it doesn=E2=80=99t happen; these need to be handled.= Stable connectivity is a layer 9 issue. By that I don=E2=80=99t mean that th= e solution is to lobby every ISP until they give up. The problem is that ri= ght now, the set of use cases that stable connectivity addresses is small. T= here is no killer app, if you will forgive the overused metaphor. If there w= ere significant use cases that created demand for stable addresses, then it w= ould be a lot harder for ISPs to insist that you not have them.=20 Making it so that we don=E2=80=99t get the best approximation of stability w= e can manage when ISPs are insisting you can=E2=80=99t have it works against= the development of that killer app, not for it. From nobody Fri Apr 10 05:34:21 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163193A08A8 for ; Fri, 10 Apr 2020 05:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 7sxdLZBb3_vx for ; Fri, 10 Apr 2020 05:34:17 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C8D083A08A7 for ; Fri, 10 Apr 2020 05:34:17 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03ACYF7h1620205 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Apr 2020 05:34:15 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03ACYF7h1620205 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586522055; bh=WgZlfPD4PLvKUnCb+ZHyMC9tVEov1KFFO06bBczn0R0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=1LIvmmBJgsJ/G8cNOkQz9hsAwCUbpbxYJWqRy83rtNbTNv6onmNPR4zMAjDqbD66P 0BHRvcx4vwoxdZxzUR4znb0A0TGFp8W1dsHRImVRLCTWsYf67Bb21OYSLkov0mgncX 9VJByRMk4YhvqD1C1zErukz5w+Ra1/g8U+TtXR8A= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <4BB07A18-CB6F-4000-8152-6B430A13CD06@consulintel.es> Date: Fri, 10 Apr 2020 05:34:15 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8D14F0DC-EA1A-4255-802D-390FD703F8B9@delong.com> References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> <5079EE4E-D48F-4C8A-ABBC-FB71DDFFC003@delong.com> <94021F65-ADBC-43E8-997C-4F0FD25EB5F0@delong.com> <4BB07A18-CB6F-4000-8152-6B430A13CD06@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 10 Apr 2020 05:34:15 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 12:34:20 -0000 In this case, however, I feel there is a need to differentiate between = persistent dynamically assigned addresses vs. persistent statically assigned addresses. Owen > On Apr 10, 2020, at 00:16 , JORDI PALET MARTINEZ = wrote: >=20 > When working in RIPE690 = (https://www.ripe.net/publications/docs/ripe-690), we found that = "persistent/non-persistent addresses" is a good way to avoid confusions = with dynamic mechanism vs dynamically assigned addresses. When I've = presented this document to different audiences, they also agreed that it = is much clearer. >=20 > So, I think it will be good to be consistent by keeping using that = terminology, and help to avoid those confusions. In fact, it will be = also good to include a non-normative reference to this document. >=20 > Regards, > Jordi > @jordipalet >=20 >=20 >=20 > =EF=BB=BFEl 10/4/20 4:27, "v6ops en nombre de Owen DeLong" = escribi=C3=B3: >=20 >=20 >=20 >> On Apr 9, 2020, at 05:48 , Philip Homburg = wrote: >>=20 >>>> Just like you can have static IPv4 addresses and still hand them = out using >>>> DHCPv4. >>>=20 >>> Nope. >>>=20 >>> Theyre fixed dynamic addresses at that point, not static addresses. >>=20 >> Call it fixed dynamic address. What does that even mean? It is = dynamic >> but never changing? >=20 > It is delegated via a dynamic mechanism, but it is not dynamically = assigned. > It is fixed in its assignment, yet dynamic in its delegation. >=20 > Thus, on the receiving end, it is still a dynamic address as the = serving end > may decide to change it at the end of any given lease period. >=20 > If you control both the client and the server, then sure, that may = never occur, > but the point is that according to the specs and the protocols, it = can. >=20 >>> Similarly, you can receive a fixed dynamic prefix via DHCP-PD, but >>> its still being issued to you dynamically and it wont keep working >>> if you dont renew the lease. >>=20 >> That very much depends on the situation. In many cases, you can keep = using=20 >> a 'fixed dynamic' IPv4 address without running a DHCP client. In = other >> cases it may not work. >=20 > You may get away with this, but it=E2=80=99s a time bomb. = Eventually, someone is > likely to update the DHCP server and depending on whether they = remember > (or know) the the host in that particular fixed address clause = isn=E2=80=99t actually > doing DHCP, life could get interesting in a number of ways. Really = bad > administrative practice as far as I=E2=80=99m concerned. If you = want to have hosts > with static addresses, then put them in a section of the network = that=E2=80=99s not > in the DHCP scope. >=20 >> But the issue is not whether external communication works or not. = When the >> router is down, there is no external communication, whether the = prefix is >> still valid or not. >=20 > I never said that the issue was external communication. If your = internet > connection goes down long enough to time out your DHCP lease, I=E2=80= =99d > think that renumbering your LAN would be among the least of your > concerns. >=20 >> However, that does not mean that local connections should break. >=20 > Nor did I say that they should. In general, an ISP using DHCP to = hand out > fixed prefixes should be choosing pretty long lease times (on the = order > of weeks if not a month or more, ideally something approximating = the > length of time for which you=E2=80=99ve paid). >=20 > In such a case, your local connections won=E2=80=99t break for many = days after > you=E2=80=99ve lost your internet connection. >=20 >> The only thing I'm asking it to allow the operator to configure = things >> differently based on the local situation. Not that it should be the = default >> or happen automatically. >=20 > Yeah, I=E2=80=99m not convinced that benefiting your corner case = exceeds the > likely harm when $END_USER who doesn=E2=80=99t know what those = timers > really mean starts playing games. >=20 > Owen >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.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 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Apr 10 05:35:52 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D3A3A08AE for ; Fri, 10 Apr 2020 05:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BvSBohFKGA7 for ; Fri, 10 Apr 2020 05:35:49 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E2B743A0876 for ; Fri, 10 Apr 2020 05:35:32 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03ACZSGm1620821 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Apr 2020 05:35:28 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03ACZSGm1620821 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586522128; bh=qIhpI8wxll6+F7On1GtuAHfeSeH/IozYUXNaURp0hck=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=cvFneyaCNxoTM2JjJ42i2M0g3gsNV241RytItZqeieRLid0a/u1xGu+EAKaeibtNu 9jHHhxBnk9fwUSgmZWq//hPXj2CQ2qf2lirYFzFz9L9smORqX9j1Pxv3VsS+kgMtvs IVxsjaiqu4TOZUNt4Gpq2rQ6ho181fD2lpu+0nV4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <20200410072902.GD50230@Space.Net> Date: Fri, 10 Apr 2020 05:35:28 -0700 Cc: Ole Troan , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4899E930-F58B-40F7-BEA8-00A114555E6B@delong.com> References: <4572EB79-812C-40A6-A93D-A61F7E2245FA@employees.org> <20200410072902.GD50230@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 10 Apr 2020 05:35:28 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 12:35:51 -0000 > On Apr 10, 2020, at 00:29 , Gert Doering wrote: >=20 > HI, >=20 > On Thu, Apr 09, 2020 at 08:54:16PM +0200, Ole Troan wrote: >> Expose the internal services in the home to the outside. = Home-assistant, ssh, xmpp server etc. >=20 > That's about O(nobody). That=E2=80=99s true today. I don=E2=80=99t expect that to necessarily = remain true in perpetuity. In fact, once we have a broader spectrum of = IPv6 deployment and IPv6-enabled console gaming systems, I=E2=80=99ll = bet that will lead the way on this issue. Owen From nobody Fri Apr 10 05:36:54 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C7F3A08A9 for ; Fri, 10 Apr 2020 05:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ky-WP0xikrV for ; Fri, 10 Apr 2020 05:36:52 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3CF3A08AA for ; Fri, 10 Apr 2020 05:36:48 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03ACakl81621260 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Apr 2020 05:36:46 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03ACakl81621260 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586522206; bh=WxGCsZNFEIVD0Yt0ik2kmpnWrmiEeCLSLx0WSNyJKcg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=3UrrseKilxvJLOfF0n0+x9cbsXFfOqtXevkeiRsCPYU7BT4iW6H6NEUAByNtHpqWu z20o+1YbitSf/UcKqfTcmCo+tD7E2YpXNMiJRRNLw/vdY+90i1NbEOyRE60pPxE9wk XkA0oW7MJVNq/HSrTITfmt0mWR4ZH464e+wE7GEc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <95DDC987-5A36-4EEF-9C0D-CB0DE782BCF9@employees.org> Date: Fri, 10 Apr 2020 05:36:46 -0700 Cc: Gert Doering , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200410072902.GD50230@Space.Net> <95DDC987-5A36-4EEF-9C0D-CB0DE782BCF9@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 10 Apr 2020 05:36:46 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 12:36:53 -0000 > On Apr 10, 2020, at 01:10 , Ole Troan wrote: >=20 >=20 >=20 >> On 10 Apr 2020, at 09:29, Gert Doering wrote: >>=20 >> =EF=BB=BFHI, >>=20 >>> On Thu, Apr 09, 2020 at 08:54:16PM +0200, Ole Troan wrote: >>> Expose the internal services in the home to the outside. = Home-assistant, ssh, xmpp server etc. >>=20 >> That's about O(nobody). >=20 > And the only value proposition IPv6 had to offer.=20 > With end users forced into ephemeral addressing the complexity of an = end to end IPv6 Internet is on par with IPv4. >=20 > If that reasoning is correct slaac-renum is the last nail in the = coffin.=20 How is it that you think SLAAC-RENUM makes this worse? I can see an = argument that it won=E2=80=99t make things any better, but I=E2=80=99m having trouble seeing how it adds any nails, let alone = being =E2=80=9Cthe last nail in the coffin=E2=80=9D. Owen From nobody Fri Apr 10 05:44:59 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522613A08D4 for ; Fri, 10 Apr 2020 05:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFscm8RmU37r for ; Fri, 10 Apr 2020 05:44:56 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 15D863A08D2 for ; Fri, 10 Apr 2020 05:44:55 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03ACip761624012 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Apr 2020 05:44:51 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03ACip761624012 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586522691; bh=lbboWSffxAhiRNq1c5sbQWDcFVydd7r+1dtxtxy//dU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=eExikvLA+Ns8/TMsH0g/SFB8wk1WI6SvKlsTuAki3uR4AZ35Msf9elYnLl9LyRjKv 2M2NLN1ZYZ0Y98GY0VEOh2mcpGJSUHIAc06m2SozQ9QIC/yOqILMgbqrZts62vJAob mPUxZfdWp+0Z8Ot2LXsdqAElnoW3u6V1zF6mfQJY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <20200410082301.GF50230@Space.Net> Date: Fri, 10 Apr 2020 05:44:51 -0700 Cc: Ole Troan , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200410072902.GD50230@Space.Net> <95DDC987-5A36-4EEF-9C0D-CB0DE782BCF9@employees.org> <20200410082301.GF50230@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 10 Apr 2020 05:44:51 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 12:44:57 -0000 > On Apr 10, 2020, at 01:23 , Gert Doering wrote: >=20 > Hi, >=20 > On Fri, Apr 10, 2020 at 10:10:27AM +0200, Ole Troan wrote: >>> On 10 Apr 2020, at 09:29, Gert Doering wrote: >>>=20 >>>> On Thu, Apr 09, 2020 at 08:54:16PM +0200, Ole Troan wrote: >>>> Expose the internal services in the home to the outside. = Home-assistant, ssh, xmpp server etc. >>>=20 >>> That's about O(nobody). >>=20 >> And the only value proposition IPv6 had to offer.=20 >=20 > "You can configure DNS entries to point at hosts in your home"? >=20 > Really? >=20 > (I thought "have enough address space so that nobody is forced to hide > behind a NAT if they do not want to" was the selling argument) The main advantage to not being stuck behind a NAT is the ability to = directly address (and reach) devices from the internet. DNS isn=E2=80=99t necessarily a requirement = for this to happen (though it helps). So indirectly, =E2=80=9CExpose the internal services in the home to = outside=E2=80=9D whether or not it involves DNS _IS_ the biggest (if not only) selling point. Not being behind NAT = is a dependency for that selling point. >> With end users forced into ephemeral addressing the complexity of an = end to end IPv6 Internet is on par with IPv4. >=20 > "Services in the home" for O(99%) never had any reasonable chance to = fly, > because normal end users just don't do that. Today. The future (if we ever enable it) can present a very different picture. > For the rest, the "WE MUST HAVE A FIREWALL IN CPEs!" discussion killed > the remaining intentions. For O(99.9999%), figuring out - if they are > not finding a random cloud offering much more convenient anyway - how > to *understand* what they need to change in their CPE, and then find = out > how to *do* it, is fairly orthogonal to what their desires are in = life. True, but CPE can evolve with user preferences over time. Likely we can = develop rational ways to ask users if an application should be permitted to = accept connections from the outside world and have the firewall automatically implement = that choice through what amounts to little more than a dialog box. Apple was able to make =E2=80=9Csudo=E2=80=9D graphical and user = friendly, surely we can eventually find a way to implement something similar for applications to ask for = the user to grant permission to the router to modify filters. Owen From nobody Fri Apr 10 05:51:43 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058B83A0902 for ; Fri, 10 Apr 2020 05:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 rSbOMiZbWiPW for ; Fri, 10 Apr 2020 05:51:39 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA65E3A0901 for ; Fri, 10 Apr 2020 05:51:38 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 369DC410AC for ; Fri, 10 Apr 2020 14:51:37 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id C29544069F; Fri, 10 Apr 2020 14:51:36 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id B3B993F023; Fri, 10 Apr 2020 14:51:36 +0200 (CEST) Date: Fri, 10 Apr 2020 14:51:36 +0200 From: Gert Doering To: Owen DeLong Cc: Gert Doering , Ole Troan , v6ops@ietf.org Message-ID: <20200410125136.GI50230@Space.Net> References: <4572EB79-812C-40A6-A93D-A61F7E2245FA@employees.org> <20200410072902.GD50230@Space.Net> <4899E930-F58B-40F7-BEA8-00A114555E6B@delong.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/5BnC5wqLBCBsuuu" Content-Disposition: inline In-Reply-To: <4899E930-F58B-40F7-BEA8-00A114555E6B@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 12:51:41 -0000 --/5BnC5wqLBCBsuuu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Apr 10, 2020 at 05:35:28AM -0700, Owen DeLong wrote: > > On Apr 10, 2020, at 00:29 , Gert Doering wrote: > > On Thu, Apr 09, 2020 at 08:54:16PM +0200, Ole Troan wrote: > >> Expose the internal services in the home to the outside. Home-assistan= t, ssh, xmpp server etc. > >=20 > > That's about O(nobody). >=20 > That???s true today. I don???t expect that to necessarily remain true in = perpetuity. In fact, once we have a broader spectrum of IPv6 deployment and= IPv6-enabled console gaming systems, I???ll bet that will lead the way on = this issue. You're going to put the IPv6 address of your gaming console into public DNS? No? We might see end-to-end talk between the devices (and I hope so), but=20 "put addresses into public DNS" is something for grey-bearded people like you and me, not for "things you buy in the supermarket that just work". Rendezvous services, registering, then talking directly. If those wonderful IETF-recommended omnipresent CPE firewalls permit. 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 --/5BnC5wqLBCBsuuu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl6Qa9UACgkQ31bAZeTO f8XDMBAAp3kzR3sg0BFTxxauVNHx8Xrp0Dtqh61hwjrVHY33yGzTtPUx3q/OYon/ D2TMPrqVPeZOwiehqORjryjXIVApUBm3bvCZHY5JwPCk0QWYy0eXGsKzaXc/THXN Aw5pBWEPZNon9DTYL2pvJVPxbLbnflof5FANP7Ct1yg1cm0IwdPoiwbuOWZYTGzr eWcUYT2tj0u4vUds1pF2ltJuXkk8nVXzfcRat3tW8FBtRD/fa7ToWpb5aEK5Aqa7 vCZpKuftR26KRRlyrfJfu+w7GZQmzpXP49pRtKZfq7I8X/Bw5++C4m7jx3M0pS/M R0HqRgAvGkDSTqtdW3HepxixmCMSBTWE4GPidOgHcZN4AuUh/Aol73euoXqHahfz RocqhklKzUedXD7I2ME34e4JN6DXeHGt/ub0A55ihml14WlyH2h4Sy5Lp2HgaVk7 S3SEAI6BWjjTYoYftr/YXz1hAkp4Yr3i0Uiw9Q4Bfe+rElLuRa1URFyBW5YGdCEE K5/96FqV79VXwjPm5HFXCpDU90W8LKml4DvTfemmtPAKwUrFbMdbT8EcupK6p46v 10cXgzrLLl57+cK1+/kgBQPLh9X0LWRgDZJ3ENabJPEmQvM7Wy483KiRGaja+Ztz HFQAghG8USbG1VFCq32EcTSvqOGcVX2dM2dYeKn2ffey+d2b3c8= =3r2K -----END PGP SIGNATURE----- --/5BnC5wqLBCBsuuu-- From nobody Fri Apr 10 06:00:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E65F3A0934 for ; Fri, 10 Apr 2020 06:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JAxWfQXa3vC for ; Fri, 10 Apr 2020 06:00:47 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 212B93A092E for ; Fri, 10 Apr 2020 06:00:47 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03AD0jsF1628937 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Apr 2020 06:00:45 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03AD0jsF1628937 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586523645; bh=qLZuyWOLID0rQ9BU9MiwqSoHyhD1AgMdHsAMvmxY/V8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=JYlY91aT2mPT1GRGWJUmlW2gCkYvP7Ceb58sAyBT6JjR7JM4Ia0RhNGFM/xxMtgcl Sd/xONNUTHQlI5ZfZPkDC1sb/MyJdXmjGI/B2d6tbQjuI7EifBcJlM/gnICECGQJYv 3X302IkLSTpCRpruRj4SmQGiVwwnQgpqkB0KM/xc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <20200410125136.GI50230@Space.Net> Date: Fri, 10 Apr 2020 06:00:45 -0700 Cc: Ole Troan , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5CF41BD0-077C-4A64-ADA1-BC426AF7D301@delong.com> References: <4572EB79-812C-40A6-A93D-A61F7E2245FA@employees.org> <20200410072902.GD50230@Space.Net> <4899E930-F58B-40F7-BEA8-00A114555E6B@delong.com> <20200410125136.GI50230@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 10 Apr 2020 06:00:45 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 13:00:48 -0000 > On Apr 10, 2020, at 05:51 , Gert Doering wrote: >=20 > Hi, >=20 > On Fri, Apr 10, 2020 at 05:35:28AM -0700, Owen DeLong wrote: >>> On Apr 10, 2020, at 00:29 , Gert Doering wrote: >>> On Thu, Apr 09, 2020 at 08:54:16PM +0200, Ole Troan wrote: >>>> Expose the internal services in the home to the outside. = Home-assistant, ssh, xmpp server etc. >>>=20 >>> That's about O(nobody). >>=20 >> That???s true today. I don???t expect that to necessarily remain true = in perpetuity. In fact, once we have a broader spectrum of IPv6 = deployment and IPv6-enabled console gaming systems, I???ll bet that will = lead the way on this issue. >=20 > You're going to put the IPv6 address of your gaming console into = public > DNS? >=20 > No? >=20 You don=E2=80=99t need to=E2=80=A6 Your gaming console will register = with a meet-me server. People you choose to play with will then receive each other=E2=80=99s = IPv6 address from the server and the consoles will connect to each other. As I said, DNS IS _NOT_ required for this to be useful. > We might see end-to-end talk between the devices (and I hope so), but=20= > "put addresses into public DNS" is something for grey-bearded people = like > you and me, not for "things you buy in the supermarket that just = work=E2=80=9D. Today, I completely agree with you. In the future, I=E2=80=99m less = certain. In the future, something like Dynamic DNS combined with authoritative servers that can be easily configured in home gateways might well become a thing. > Rendezvous services, registering, then talking directly. Yes, this will almost certainly be the first wave. It still requires the = ability to get the firewall to move the fsck out of the way. > If those wonderful IETF-recommended omnipresent CPE firewalls permit. Obviously what is needed (and lacking so far) is a standardized = mechanism by which a device can pass along a dialog to the user which allows the user to = authenticate and grant permission to the router to allow the flows requested by the = {device, application}. I have no precise idea what that mechanism or process looks like, but I = have enough general ideas of ways it could work to say that it really wouldn=E2=80=99t= be all that difficult to implement if we can get the right people to pull their collective heads = out of their collective rumps. Owen From nobody Fri Apr 10 06:02:46 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263953A093B for ; Fri, 10 Apr 2020 06:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kt5VHXU_05c4 for ; Fri, 10 Apr 2020 06:02:43 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8987D3A093A for ; Fri, 10 Apr 2020 06:02:43 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2FE714390F for ; Fri, 10 Apr 2020 15:02:42 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id A72CD4069F; Fri, 10 Apr 2020 15:02:41 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 9896A3F3E8; Fri, 10 Apr 2020 15:02:41 +0200 (CEST) Date: Fri, 10 Apr 2020 15:02:41 +0200 From: Gert Doering To: Owen DeLong Cc: Gert Doering , Ole Troan , v6ops@ietf.org Message-ID: <20200410130241.GK50230@Space.Net> References: <4572EB79-812C-40A6-A93D-A61F7E2245FA@employees.org> <20200410072902.GD50230@Space.Net> <4899E930-F58B-40F7-BEA8-00A114555E6B@delong.com> <20200410125136.GI50230@Space.Net> <5CF41BD0-077C-4A64-ADA1-BC426AF7D301@delong.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Bcd/voCMeTy3OlaS" Content-Disposition: inline In-Reply-To: <5CF41BD0-077C-4A64-ADA1-BC426AF7D301@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 13:02:45 -0000 --Bcd/voCMeTy3OlaS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Apr 10, 2020 at 06:00:45AM -0700, Owen DeLong wrote: > > If those wonderful IETF-recommended omnipresent CPE firewalls permit. >=20 > Obviously what is needed (and lacking so far) is a standardized mechanism= by which > a device can pass along a dialog to the user which allows the user to aut= henticate and > grant permission to the router to allow the flows requested by the {devic= e, application}. Of course this will need to make it very clear if the intent of said communication is benign or malicious. Otherwise, users can not make a educated choice. 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 --Bcd/voCMeTy3OlaS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl6QbnAACgkQ31bAZeTO f8UN+w/+KXZBdCfL2E+nEOSMpk+klQbSE+EvWWnA18O4UuhrqOWg5jG41m6IHRLu iO+GVVI7QUu3LzOyOmY2jVHHng+tfUwdYDmQkFgwnbbTr/k8LtflZzndasZ4FDDm zHCqeEK5Zphjh9oArN4iFG8hrIAvD6j2ZOkNzC8fMM2Ev3GSwTD3nly0htiU3rPk qGv4RX+qS9mFnarAkbx4drMDv5fQTlAnCd9UhL2cferdB1to1uNUoTfP64izJaoX 99RfhuArbFr02EmJV8naCderk+MNv04kYYR+69oy2jBm0vhQSqHSdlRiT+2OJIxd UcQervOfETaob/UkWaHQx0g3o39lJbWvQlg3sK/7/4S5kTQIdgMxDNL98XeKX9f7 5vbPYeRuQb5KjOGWLPgrPR8h+bceZb+RRtoMvxI8CezYQ/MXD4AmS7w/4ABZQ20U 08QIBmro4rHtAKIw8ZrxefbWrmVzLSnnqJBcIhBtuYsQwtkuZ6il6mtwbQEkgh07 SVLleMbXXQvNxDsrf3vBCiQpEM/UjXufa6PGv9BZl3SetzF4j4jWrAi65EBvzXxx EXXHLCfoMoXJzr5732Onv/x8HcWN2AND7D1xljFd8YgdjXIenHtqgEBGOVEXdvjO nskoAhoaNZbGDVQmRd6GwGBBQhXkZA6zzGMSFPNka3GhNUMPNlc= =YKmq -----END PGP SIGNATURE----- --Bcd/voCMeTy3OlaS-- From nobody Fri Apr 10 06:11:18 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC263A0969 for ; Fri, 10 Apr 2020 06:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wscQNcKG0XmA for ; Fri, 10 Apr 2020 06:11:15 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 283DF3A0965 for ; Fri, 10 Apr 2020 06:11:15 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03ADBCWj1632207 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Apr 2020 06:11:12 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03ADBCWj1632207 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586524272; bh=a3rhKzWVxuhH1L9ZBbppT4vf5/zJCF3PGMpI7ZyKU40=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=mYNa9CCSvDs7+fDucKcSisze/ELCi/TsE+0xkNIdGC3hezd8lWiWP+USoVx25FjSG O+U9ZngI/IWMFFro3+EsILwrIjhfQ/0qDlZ8SQs6xAOVuVnk2LkbFhrYO61OX25Z7o 6xGc/5uSAKr8F5w3Hz+YxFhIvoFZx/YaXb2lF3wY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <20200410130241.GK50230@Space.Net> Date: Fri, 10 Apr 2020 06:11:12 -0700 Cc: Ole Troan , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9E52F36C-53C5-4092-B6BC-C431C1B90F67@delong.com> References: <4572EB79-812C-40A6-A93D-A61F7E2245FA@employees.org> <20200410072902.GD50230@Space.Net> <4899E930-F58B-40F7-BEA8-00A114555E6B@delong.com> <20200410125136.GI50230@Space.Net> <5CF41BD0-077C-4A64-ADA1-BC426AF7D301@delong.com> <20200410130241.GK50230@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 10 Apr 2020 06:11:12 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 13:11:17 -0000 > On Apr 10, 2020, at 06:02 , Gert Doering wrote: >=20 > Hi, >=20 > On Fri, Apr 10, 2020 at 06:00:45AM -0700, Owen DeLong wrote: >>> If those wonderful IETF-recommended omnipresent CPE firewalls = permit. >>=20 >> Obviously what is needed (and lacking so far) is a standardized = mechanism by which >> a device can pass along a dialog to the user which allows the user to = authenticate and >> grant permission to the router to allow the flows requested by the = {device, application}. >=20 > Of course this will need to make it very clear if the intent of said > communication is benign or malicious. Otherwise, users can not make a > educated choice. You want to ask the malware to identify itself as malware=E2=80=A6 Uh, = good luck with that. Users are allowed to make uninformed choices about what URLs they click = on every day. Obviously this is an extension of that paradigm. OTOH, the user should be presented with some confidence in which = application and/or device is making the request (He=E2=80=99s viewing the request on the device = and the OS could be required to disclose the Application and whether or not it=E2=80=99s a validly = signed package; if so, who the manufacturer is, etc.). There could also be a requirement that the = contact point for inbound traffic is not allowed to be an ephemeral port. (This would require a = mechanism for requesting/ registering service ports with the OS). Further protection could be afforded by the OS denying listeners binding = to that port if they don=E2=80=99t match the application signature in question. (This would = require a signed mechanism for updating signatures during application updates). However, it=E2=80=99s not like any of this requires new or novel = technology. It just requires combining existing solved problems in a novel way. Owen From nobody Fri Apr 10 06:27:02 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7440C3A09D0 for ; Fri, 10 Apr 2020 06:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_KmPsJH5BgP for ; Fri, 10 Apr 2020 06:26:59 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0380F3A09CE for ; Fri, 10 Apr 2020 06:26:58 -0700 (PDT) Received: from [IPv6:2a01:79d:53aa:d30:d5d9:904:139a:cd] (unknown [IPv6:2a01:79d:53aa:d30:d5d9:904:139a:cd]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 1732B4E11A5E; Fri, 10 Apr 2020 13:26:58 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Fri, 10 Apr 2020 15:26:54 +0200 Message-Id: <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> References: Cc: Gert Doering , v6ops@ietf.org In-Reply-To: To: Owen DeLong X-Mailer: iPhone Mail (17E255) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 13:27:00 -0000 > On 10 Apr 2020, at 14:36, Owen DeLong wrote: >=20 > =EF=BB=BF >=20 >>> On Apr 10, 2020, at 01:10 , Ole Troan wrote: >>>=20 >>>=20 >>>=20 >>>> On 10 Apr 2020, at 09:29, Gert Doering wrote: >>>=20 >>> =EF=BB=BFHI, >>>=20 >>>> On Thu, Apr 09, 2020 at 08:54:16PM +0200, Ole Troan wrote: >>>> Expose the internal services in the home to the outside. Home-assistant= , ssh, xmpp server etc. >>>=20 >>> That's about O(nobody). >>=20 >> And the only value proposition IPv6 had to offer.=20 >> With end users forced into ephemeral addressing the complexity of an end t= o end IPv6 Internet is on par with IPv4. >>=20 >> If that reasoning is correct slaac-renum is the last nail in the coffin.=20= >=20 > How is it that you think SLAAC-RENUM makes this worse? I can see an argume= nt that it won=E2=80=99t make things any better, > but I=E2=80=99m having trouble seeing how it adds any nails, let alone bei= ng =E2=80=9Cthe last nail in the coffin=E2=80=9D. It=E2=80=99s logically the same argument Lorenzo uses against DHCPv6.=20 If we modify the IPv6 protocols to accommodate ephemeral addressing, then th= ere is no incentive for operators to offer anything else.=20 That creates a set of second class citizen end-user networks. Any service ne= eds to accommodate the smallest common denominator. Which means you need nat= and firewall traversal, deal with addresses being pulled out from underneat= h you... Are there other benefits to end users that IPv6 offers than end to end trans= parency? I can run a service by just taking the address on the host interfac= e and stuff it in DNS.=20 With ephemeral addressing that=E2=80=99s quite a bit harder. And there is ge= nerally no tools supporting this model deployed.=20 Can anyone think of an argument for why a user on such a network would not b= e better off sticking to IPv4 and NAT? Cheers=20 Ole From nobody Fri Apr 10 06:40:42 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9143A0A87 for ; Fri, 10 Apr 2020 06:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 YEPHN4rfq16A for ; Fri, 10 Apr 2020 06:40:27 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 639043A0A8D for ; Fri, 10 Apr 2020 06:40:00 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03ADduij1641434 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Apr 2020 06:39:56 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03ADduij1641434 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586525997; bh=mStx/o6x11Fwd37QiQZOL2OhLtv7H3Al8W7unmt7/0A=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=iGI4BuIrVdw54kDeYaOSktEid1DxavFqCaPgU/IHB6ac9X/mzx5+anLCtvw8AFEps icofYt8WhVH03vj/NjiysgANdUdhyu1DHbLI5aEFlwcQ+J5C8kAOPSh+i0wSLGG1Dl UDhezDmLUI6Zt1CtnXhGKHr1tRaG2l8CTnnLsvyg= From: Owen DeLong Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F6F579A8-C5FC-429E-94EE-5A93EE774336" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 10 Apr 2020 06:39:56 -0700 In-Reply-To: <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> Cc: Gert Doering , v6ops@ietf.org To: Ole Troan References: <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 10 Apr 2020 06:39:57 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 13:40:38 -0000 --Apple-Mail=_F6F579A8-C5FC-429E-94EE-5A93EE774336 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 10, 2020, at 06:26 , Ole Troan wrote: >=20 >=20 >=20 >> On 10 Apr 2020, at 14:36, Owen DeLong wrote: >>=20 >> =EF=BB=BF >>=20 >>>> On Apr 10, 2020, at 01:10 , Ole Troan wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On 10 Apr 2020, at 09:29, Gert Doering wrote: >>>>=20 >>>> =EF=BB=BFHI, >>>>=20 >>>>> On Thu, Apr 09, 2020 at 08:54:16PM +0200, Ole Troan wrote: >>>>> Expose the internal services in the home to the outside. = Home-assistant, ssh, xmpp server etc. >>>>=20 >>>> That's about O(nobody). >>>=20 >>> And the only value proposition IPv6 had to offer.=20 >>> With end users forced into ephemeral addressing the complexity of an = end to end IPv6 Internet is on par with IPv4. >>>=20 >>> If that reasoning is correct slaac-renum is the last nail in the = coffin.=20 >>=20 >> How is it that you think SLAAC-RENUM makes this worse? I can see an = argument that it won=E2=80=99t make things any better, >> but I=E2=80=99m having trouble seeing how it adds any nails, let = alone being =E2=80=9Cthe last nail in the coffin=E2=80=9D. >=20 > It=E2=80=99s logically the same argument Lorenzo uses against DHCPv6.=20= >=20 > If we modify the IPv6 protocols to accommodate ephemeral addressing, = then there is no incentive for operators to offer anything else.=20 Uh, I don=E2=80=99t buy that. It strikes me as a false dichotomy. = Operators can actually reduce operational cost and complexity by = offering relatively stable prefixes. > That creates a set of second class citizen end-user networks. Any = service needs to accommodate the smallest common denominator. Which = means you need nat and firewall traversal, deal with addresses being = pulled out from underneath you=E2=80=A6 If you take the first argument as a given (and I don=E2=80=99t) this is = a reasonable conclusion on the effect. However, it completely falls = apart if your first postulate turns out false. > Are there other benefits to end users that IPv6 offers than end to end = transparency? I can run a service by just taking the address on the host = interface and stuff it in DNS.=20 Meh=E2=80=A6 You can run a service without DNS as well. > With ephemeral addressing that=E2=80=99s quite a bit harder. And there = is generally no tools supporting this model deployed.=20 It=E2=80=99s a little bit harder. Plenty of solutions exist for updating = DNS dynamically to reflect address changes. These even existed for the = public side of portmaps in IPv4, complete with GUI interfaces on routers = sufficiently stupid that plenty of home users were able to make them = work. > Can anyone think of an argument for why a user on such a network would = not be better off sticking to IPv4 and NAT? Not sure. I=E2=80=99d have to give it some thought. Given the general = direction of a multitude of eyeball ISPs, I=E2=80=99m not sure they=E2=80=99= ll have much choice in the matter in a few years. Likely they=E2=80=99ll either have to give up their IPv4 addresses when = their ISP drops IPv4 from its service offering, or, they=E2=80=99ll have = to start paying extra to keep IPv4 when it stops becoming a standard = part of ISP services. Those will probably be the most compelling reasons. However, this still hinges on the assumption that ISPs will behave in = the manner you describe. I remain unconvinced that will be the case. Owen --Apple-Mail=_F6F579A8-C5FC-429E-94EE-5A93EE774336 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 10, 2020, at 06:26 , Ole Troan <otroan@employees.org> wrote:



On 10 = Apr 2020, at 14:36, Owen DeLong <owen@delong.com> wrote:

=EF=BB=BF

On Apr 10, = 2020, at 01:10 , Ole Troan <otroan@employees.org> wrote:



On 10 Apr 2020, at 09:29, Gert Doering <gert@space.net> = wrote:

=EF=BB=BFHI,

On Thu, = Apr 09, 2020 at 08:54:16PM +0200, Ole Troan wrote:
Expose = the internal services in the home to the outside. Home-assistant, ssh, = xmpp server etc.

That's about = O(nobody).

And the only value = proposition IPv6 had to offer. 
With end = users forced into ephemeral addressing the complexity of an end to end = IPv6 Internet is on par with IPv4.

If that = reasoning is correct slaac-renum is the last nail in the coffin. 

How is it that you think = SLAAC-RENUM makes this worse? I can see an argument that it won=E2=80=99t = make things any better,
but I=E2=80=99m having trouble = seeing how it adds any nails, let alone being =E2=80=9Cthe last nail in = the coffin=E2=80=9D.

It=E2=80=99s logically the same argument Lorenzo uses against = DHCPv6. 

If we modify the IPv6 protocols = to accommodate ephemeral addressing, then there is no incentive for = operators to offer anything else. 

Uh, I don=E2=80=99= t buy that. It strikes me as a false dichotomy. Operators can actually = reduce operational cost and complexity by offering relatively stable = prefixes.

That creates a set of second class citizen end-user networks. = Any service needs to accommodate the smallest common denominator. Which = means you need nat and firewall traversal, deal with addresses being = pulled out from underneath you=E2=80=A6

If you take the first argument as a given (and I = don=E2=80=99t) this is a reasonable conclusion on the effect. However, = it completely falls apart if your first postulate turns out = false.

Are there = other benefits to end users that IPv6 offers than end to end = transparency? I can run a service by just taking the address on the host = interface and stuff it in DNS. 

Meh=E2=80=A6 You = can run a service without DNS as well.

With ephemeral addressing = that=E2=80=99s quite a bit harder. And there is generally no tools = supporting this model deployed. 

It=E2=80=99s a = little bit harder. Plenty of solutions exist for updating DNS = dynamically to reflect address changes. These even existed for the = public side of portmaps in IPv4, complete with GUI interfaces on routers = sufficiently stupid that plenty of home users were able to make them = work.

Can anyone = think of an argument for why a user on such a network would not be = better off sticking to IPv4 and NAT?

Not sure. I=E2=80=99d have to give it some = thought. Given the general direction of a multitude of eyeball ISPs, = I=E2=80=99m not sure they=E2=80=99ll have much choice in the matter in a = few years.

Likely = they=E2=80=99ll either have to give up their IPv4 addresses when their = ISP drops IPv4 from its service offering, or, they=E2=80=99ll have to = start paying extra to keep IPv4 when it stops becoming a standard part = of ISP services.

Those will probably be the most compelling reasons.

However, this still = hinges on the assumption that ISPs will behave in the manner you = describe. I remain unconvinced that will be the case.

Owen

= --Apple-Mail=_F6F579A8-C5FC-429E-94EE-5A93EE774336-- From nobody Fri Apr 10 09:02:37 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1424D3A03FE for ; Fri, 10 Apr 2020 09:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNOWHzGHJOXj for ; Fri, 10 Apr 2020 09:02:34 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3E73A03FC for ; Fri, 10 Apr 2020 09:02:34 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0375F43937 for ; Fri, 10 Apr 2020 18:02:32 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id C71E043934; Fri, 10 Apr 2020 18:02:31 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id B81EB6A5EC; Fri, 10 Apr 2020 18:02:31 +0200 (CEST) Date: Fri, 10 Apr 2020 18:02:31 +0200 From: Gert Doering To: Ole Troan Cc: Owen DeLong , Gert Doering , v6ops@ietf.org Message-ID: <20200410160231.GM50230@Space.Net> References: <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aLIW9cxZFr2Nfp3T" Content-Disposition: inline In-Reply-To: <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> X-NCC-RegID: de.space User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 16:02:36 -0000 --aLIW9cxZFr2Nfp3T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Apr 10, 2020 at 03:26:54PM +0200, Ole Troan wrote: > If we modify the IPv6 protocols to accommodate ephemeral addressing, then= there is no incentive for operators to offer anything else.=20 >=20 > That creates a set of second class citizen end-user networks. Any service= needs to accommodate the smallest common denominator. Which means you need= nat and firewall traversal, deal with addresses being pulled out from unde= rneath you... Welcome to the Internet of 2020. Actually, applications that can deal with "oops, my hosts's address changed behind my back, so what" are something we need to see - devices are mobile, roam between LAN and wifi and LTE, addresses change all the time, and=20 users expect things like audio/video streams to continue seamlessly. In that scenario, insisting on "butbutbut my home network address must=20 never change!" is somewhat irrelevant in the grand picture. > Are there other benefits to end users that IPv6 offers than end to end tr= ansparency? I can run a service by just taking the address on the host inte= rface and stuff it in DNS.=20 CGN hurts. So yes, not having N:1 being forced on you is a benefit of IPv6. > Can anyone think of an argument for why a user on such a network would no= t be better off sticking to IPv4 and NAT? These days, people observe that their VPNs work much less reliably behind a N:1 IPv4 NAT than via IPv6... 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 --aLIW9cxZFr2Nfp3T Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl6QmJUACgkQ31bAZeTO f8U4lg/7BQjLTzsIG0fb1+Sr6R5l4nrywD/9fvZymCgYc90vH19duGrO18XrjHeY VQWz/PJuY61aGftn0ynxWXHa2SmUnvgV5bZSzNjKVXCgoNil0/0gpMjqoUeNbDtZ 1/oRczeuw+1+0iHRF3DrPuvUJ/jwPS9MUyucgoE7406jkP/Pu9YXxcUZo0Pi87DM rPnRDUXhsPys/ZgireqxaCtmHuv+GdCHubn7SfsZutjEn+qggorJDyCd9Dm9lLUG pOg+uJigLgON3yuySTtIKhLYYZlkmDKz3YeOp5L66YcnkdqnbQLkUxbRiDph22/r kqFN9AjCXW8/As0Ktt2san85bstSN6nypYVmPjqvg5ohR5Kqcjnz3WP5ckSVx5TT tNzLoPx/x0/AoXs3RVmsVX/XsFBo7by6l79hTYKB0Hp3thP0cReNQ8OOt3Q5Vf9z 3AGMD7QApyj+jjZJpcbfnrqYN7Py3zGLLIcnrXfKSs8kaYKpHhwfrIenLuoYXTvE 8TXFUCPuOw75DFij/So5LeswSF3KoBZyEAJONLyBHz3Zv3JtpQtfTzy9z4bEUwsM awyAIEGCVshSOnWiJhZpHXpHTdf3cmb1Q34PB463ztA0AtYBdkJEf/unTPavDLY3 59e3DgT8/Uc0rkWA4IMX7Whaypy+D+zB48ldsve9MozxQYCs1iw= =kgFd -----END PGP SIGNATURE----- --aLIW9cxZFr2Nfp3T-- From nobody Fri Apr 10 12:30:04 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF553A03EA for ; Fri, 10 Apr 2020 12:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 qJnAXss8gxjW for ; Fri, 10 Apr 2020 12:30:01 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABCC3A0365 for ; Fri, 10 Apr 2020 12:30:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from simons-macbookpro.thehobsons.co.uk (Simons-MacBookPro.thehobsons.co.uk [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 2584E6400D for ; Fri, 10 Apr 2020 19:29:57 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Hobson In-Reply-To: Date: Fri, 10 Apr 2020 20:29:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5E5E16A8-DB7A-49E7-A755-89BE3C859EC8@thehobsons.co.uk> References: <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> To: v6ops list X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 19:30:03 -0000 Owen DeLong wrote: > Uh, I don=E2=80=99t buy that. It strikes me as a false dichotomy. = Operators can actually reduce operational cost and complexity by = offering relatively stable prefixes. Maybe, but some go out of their way to not provide them. Now I don't = know about what they are offering with IPv6, but with a previous work = hat on I had a first hand view of what a number of (mostly UK) ISPs did = with IPv4. Some ISPs will not under any circumstances allow a fixed IP Some ISPs will only allow a fixed IP if you pay extra for a business = connection Some ISPs even charge extra for a fixed IP if you are already paying = extra for a "business" connection Some ISPs are happy to let you choose. Mine is one of them, and the only = charge they make for a fixed IP is a one-off charge when you tick the = box in the control panel. The usual answer (already mentioned) for "why no fixed address" is = simply that they want to make it hard for you to do anything they think = is not "consumer" stuff. If you have a consumer grade connection, then = you are only allowed to consume - not serve. If you want to do anything = not "consumer" - such as hosting a server, or having a site-site VPN - = then you have to pay more for a "business" connection. It seems that teh = marketing departments of these ISPs haven't heard of dynamic DNS = services ! So yes, it may be simpler and cheaper for an operator to offer stable = prefixes - but if what I've seen with IPv4 is anything to go by, they'll = be happy to pay extra to have something to upsell the user with. And = sometimes the upsell if a quite significant additional cost. The "but IPv6 address space is so huge, there's no scarcity you can = charge for" is irrelevant. IPSs were doing the "pay extra for fixed = address" thing back when IPv4 addresses had no scarcity value either. Never underestimate the technical stupidity of the marketing and finance = departments ! If the marketing department sees the value of scamming = users for static prefixes, then it matters not what is in the RFCs. Simon From nobody Fri Apr 10 12:30:41 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71CB3A03F1 for ; Fri, 10 Apr 2020 12:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tv7czGsp1sKL for ; Fri, 10 Apr 2020 12:30:38 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42BA13A0405 for ; Fri, 10 Apr 2020 12:30:28 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jMzM0-0000L6C; Fri, 10 Apr 2020 21:30:16 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> <5079EE4E-D48F-4C8A-ABBC-FB71DDFFC003@delong.com> <94021F65-ADBC-43E8-997C-4F0FD25EB5F0@delong.com> In-reply-to: Your message of "Thu, 9 Apr 2020 19:26:36 -0700 ." <94021F65-ADBC-43E8-997C-4F0FD25EB5F0@delong.com> Date: Fri, 10 Apr 2020 21:30:14 +0200 Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 19:30:40 -0000 > > Call it fixed dynamic address. What does that even mean? It is dynamic > > but never changing? > > It is delegated via a dynamic mechanism, but it is not dynamically > assigned. It is fixed in its assignment, yet dynamic in its > delegation. > > Thus, on the receiving end, it is still a dynamic address as the > serving end may decide to change it at the end of any given lease > period. If the assignment is fixed, then the serving end does not change it at the end of any lease period. If it does change then that is an operational error, because, as said before, the assignment is fixed. This is similar the DNS, it is not as if the registry is free to change a DNS delegation at the end of a TTL. This change can only happen for other reasons, in particular at the request of a registrar. > I never said that the issue was external communication. If your > internet connection goes down long enough to time out your DHCP > lease, Id think that renumbering your LAN would be among the least > of your concerns. No. an ISPs, short DHCP leases are preferred. The reason is that when people swap out CPEs, sometimes the old lease is stuck to the old CPE and the new one gets a lease only when the old one expires. > Nor did I say that they should. In general, an ISP using DHCP to > hand out fixed prefixes should be choosing pretty long lease times > (on the order of weeks if not a month or more, ideally something > approximating the length of time for which youve paid). 2 hours is not pretty long in my book. This is reality. Not some sort of ideal case. > In such a case, your local connections wont break for many days > after youve lost your internet connection. 2 hours is not many days in my book. > Yeah, Im not convinced that benefiting your corner case exceeds > the likely harm when $END_USER who doesnt know what those timers > really mean starts playing games. Of course a RFC should know better than an operator, even when that operator is called 'user'. That's the right attitude to get IPv6 adopted. From nobody Fri Apr 10 12:38:37 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15F93A0817 for ; Fri, 10 Apr 2020 12:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OBA73G6YZJ7 for ; Fri, 10 Apr 2020 12:38:34 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A243A0813 for ; Fri, 10 Apr 2020 12:38:33 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 03AJcPIq036299 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2020 20:38:25 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Ole Troan Cc: v6ops@ietf.org References: <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> From: Nick Hilliard Message-ID: <01edb0e8-211a-2bdc-1bc5-c0c530b84dd8@foobar.org> Date: Fri, 10 Apr 2020 20:38:24 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.12 MIME-Version: 1.0 In-Reply-To: <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 19:38:36 -0000 Ole Troan wrote on 10/04/2020 14:26: > It’s logically the same argument Lorenzo uses against DHCPv6. > > If we modify the IPv6 protocols to accommodate ephemeral addressing, > then there is no incentive for operators to offer anything else. this argument is fact-free nonsense. And yes, that particular argument of Lorenzo against DHCPv6 is also nonsense. Nick From nobody Fri Apr 10 12:38:55 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580EF3A0870 for ; Fri, 10 Apr 2020 12:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne0o6i08P5hK for ; Fri, 10 Apr 2020 12:38:46 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E263A08AB for ; Fri, 10 Apr 2020 12:38:45 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jMzU3-0000LzC; Fri, 10 Apr 2020 21:38:35 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> In-reply-to: Your message of "Fri, 10 Apr 2020 15:26:54 +0200 ." <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> Date: Fri, 10 Apr 2020 21:38:24 +0200 Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 19:38:53 -0000 > If we modify the IPv6 protocols to accommodate ephemeral addressing, > then there is no incentive for operators to offer anything else. This is something the market will solve if we won't. It is already years ago that AVM FRITZ!Box had a misfeature that it would try to deprecate prefixes it didn't hand out itself. I can imagine plenty of hacks that can 'solve' this problem while creating lots of others. RAs at a high frequency were already mentioned. From nobody Fri Apr 10 12:46:18 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C7C3A08EB for ; Fri, 10 Apr 2020 12:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVyB2n4oKgfk for ; Fri, 10 Apr 2020 12:46:12 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EB0AC3A08E7 for ; Fri, 10 Apr 2020 12:46:11 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03AJkBQW1765021 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Apr 2020 12:46:11 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03AJkBQW1765021 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586547971; bh=NejFGlIwtW7rdqqhNh3Y/fSNeP2olA+tFtuEJbqYLDY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=v47ImPyojC6DxWU4TFrjNnuah9TuaWR6Qdnh939ESK6/tkFQXYcTxVKdf4ciQQXdL 809yhsoypHqk9XeqIYDGHvWQQ83i/Sz4zOcgrwk+Bg9P+5XMt3DN5Z4ceVcewJS9qd xF10lviP/jQ+z2NI4ddEOpb+m8gBR/vyDaQuohXM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <5E5E16A8-DB7A-49E7-A755-89BE3C859EC8@thehobsons.co.uk> Date: Fri, 10 Apr 2020 12:46:10 -0700 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <2E05CD30-7264-4D35-BC19-B4A1C2851CAF@delong.com> References: <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> <5E5E16A8-DB7A-49E7-A755-89BE3C859EC8@thehobsons.co.uk> To: Simon Hobson X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 10 Apr 2020 12:46:11 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 19:46:16 -0000 > On Apr 10, 2020, at 12:29 , Simon Hobson = wrote: >=20 > Owen DeLong wrote: >=20 >> Uh, I don=E2=80=99t buy that. It strikes me as a false dichotomy. = Operators can actually reduce operational cost and complexity by = offering relatively stable prefixes. >=20 > Maybe, but some go out of their way to not provide them. Now I don't = know about what they are offering with IPv6, but with a previous work = hat on I had a first hand view of what a number of (mostly UK) ISPs did = with IPv4. If they=E2=80=99re trying that hard, nothing prevents them from giving = the end user a /128 with NAT66 and ULA in the home. > Some ISPs will not under any circumstances allow a fixed IP No sane ISP will provide a static IP to residential end users, = especially on a CMTS or *PON system. Now, fixed is a different matter, but quite often they won=E2=80=99t = want to make that guarantee. The only ISPs I know of that are deliberately rotating IPv6 addresses = frequently whether their customers want it or not are some silly = European ISPs that have this strange notion that it protects their = customer=E2=80=99s privacy and that they know better about what their = customer wants or needs, even if their customer is loudly proclaiming = otherwise. Most of the ones I know about like this are in Germany which = has a long history of misguided privacy rules, regulations, and ideas. = The Netherlands are not far removed. > Some ISPs will only allow a fixed IP if you pay extra for a business = connection I=E2=80=99ve seen more of this in IPv4 than in IPv6, but most of the = ones that do in IPv6 secretly give you an IP address that is very = unlikely to change unless they change the network topology above you in = which case, yeah, that=E2=80=99s going to happen unless you pay extra to = cover their overhead in dealing with it. This doesn=E2=80=99t seem = unreasonable to me. > Some ISPs even charge extra for a fixed IP if you are already paying = extra for a "business=E2=80=9D connection Right=E2=80=A6 Again, especially on CMTS and *PON, see above. > Some ISPs are happy to let you choose. Mine is one of them, and the = only charge they make for a fixed IP is a one-off charge when you tick = the box in the control panel. That=E2=80=99s great, but it sounds like they=E2=80=99re still issuing a = fixed dynamic prefix rather than allowing for a static configuration. = They=E2=80=99re doing this for a variety of reasons of operational = convenience. If you pay them monthly, then you should be getting DHCP = IA_PD offers that have at least a 1 month valid time. If you=E2=80=99re = not, you should be asking them why not. If you are, then you really = shouldn=E2=80=99t be suffering a problem with your LAN when your ISP = goes down. Surely they can restore service in less than 15 days? If not, = is renumbering your LAN really your biggest problem? If so, I gotta = say=E2=80=A6 =E2=80=9CFirst world problems, dude." > The usual answer (already mentioned) for "why no fixed address" is = simply that they want to make it hard for you to do anything they think = is not "consumer" stuff. If you have a consumer grade connection, then = you are only allowed to consume - not serve. If you want to do anything = not "consumer" - such as hosting a server, or having a site-site VPN - = then you have to pay more for a "business" connection. It seems that teh = marketing departments of these ISPs haven't heard of dynamic DNS = services ! That answer is pretty silly. I=E2=80=99ve easily worked around it by = getting my own addresses and ASN from an RIR and using GRE. My = less-than-cooperative ISP is merely layer 2 transport. I realize this = isn=E2=80=99t an option open to everyone, but it works well for me. Besides, if they issue you a relatively stable prefix, it=E2=80=99s = certainly not hard to do things which aren=E2=80=99t =E2=80=9Cconsumer=E2=80= =9D, including hosting all kinds of services and site-to-site VPNs. = Heck, it=E2=80=99s pretty basic to do a site-to-site VPN any place you = have at least one fixed end-point these days and even if you don=E2=80=99t= , there are reasonable workarounds. I know one guy who managed to spin = up an ultra cheap container or VM or whatever when the two sites lost = track of each other and they=E2=80=99d both send their current address = to each other via a proxy server running on that instance, and then once = the connection was re-established, both sides would sent it a virtual = thumbs up and it would go back to sleep until one side or the other = called for it again. Since it only ran for about 20 seconds when a = renumbering event occurred (every few years), it=E2=80=99s compute bill = was so minuscule that it took like 8 years to rack up enough charges to = generate a bill. > So yes, it may be simpler and cheaper for an operator to offer stable = prefixes - but if what I've seen with IPv4 is anything to go by, they'll = be happy to pay extra to have something to upsell the user with. And = sometimes the upsell if a quite significant additional cost. IPv6 !=3D IPv4 and most operators seem to be somewhat clueful about that = (at least the bigger ones). > The "but IPv6 address space is so huge, there's no scarcity you can = charge for" is irrelevant. IPSs were doing the "pay extra for fixed = address" thing back when IPv4 addresses had no scarcity value either. Not nearly as widespread, however. Also, fixed addresses in IPv4 in a = CMTS or *PON are actually hard. Stable addresses in IPv6 that change = very rarely are easy. Fixed addresses are less easy. This has nothing to = do with billing models, it=E2=80=99s operational nature of the beast. > Never underestimate the technical stupidity of the marketing and = finance departments ! If the marketing department sees the value of = scamming users for static prefixes, then it matters not what is in the = RFCs. Oh, I don=E2=80=99t, but I also know that they=E2=80=99ll chase the = dollars and if it costs them $15/subscriber/month in engineering time to = cope with the problems created by playing musical prefixes to gain $10 = per subscriber, it won=E2=80=99t last long. Owen From nobody Fri Apr 10 13:02:57 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCE13A0B91 for ; Fri, 10 Apr 2020 13:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 VNf06PxJeOsg for ; Fri, 10 Apr 2020 13:02:53 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E93A0B92 for ; Fri, 10 Apr 2020 13:02:53 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03AK2q4i1771501 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Apr 2020 13:02:52 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03AK2q4i1771501 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586548972; bh=uuyiAgyX5uN7oKnKqMmJ/NZwZvzmGVwiUQbYCIlXhWw=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=Z5qmNASdI5jl7FNxGXNLIPjHEJ0GUjSvuU37btWP/5xHP0iaKaeuFRc1nShdOl3mf 8D/LYB8zejfKbk8aYZotRNyaDZqeACZ3POdvaLDJQbT74QTipjbRkfIK4LJeppYzNa Z15aPsIYtmSifPWNqyS7HgdivTl3LhrDq8jVc7lU= From: Owen DeLong Message-Id: <8D8BA28B-2DE7-4414-840C-28FCB8C4E915@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_23A43AF5-1917-4F88-A8F9-719555086DFC" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 10 Apr 2020 13:02:52 -0700 In-Reply-To: Cc: v6ops@ietf.org To: Philip Homburg References: <040b3cee-b51f-cac0-7c99-14a37fba7874@si6networks.com> <006D0357-766F-4CC6-9EA7-3A16720B3A46@employees.org> <5079EE4E-D48F-4C8A-ABBC-FB71DDFFC003@delong.com> <94021F65-ADBC-43E8-997C-4F0FD25EB5F0@delong.com> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 10 Apr 2020 13:02:52 -0700 (PDT) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 20:02:56 -0000 --Apple-Mail=_23A43AF5-1917-4F88-A8F9-719555086DFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 10, 2020, at 12:30 , Philip Homburg = wrote: >=20 >>> Call it fixed dynamic address. What does that even mean? It is = dynamic >>> but never changing? >>=20 >> It is delegated via a dynamic mechanism, but it is not dynamically >> assigned. It is fixed in its assignment, yet dynamic in its >> delegation. >>=20 >> Thus, on the receiving end, it is still a dynamic address as the >> serving end may decide to change it at the end of any given lease >> period. >=20 > If the assignment is fixed, then the serving end does not change it at = the > end of any lease period. If it does change then that is an operational > error, because, as said before, the assignment is fixed. Nope=E2=80=A6 It=E2=80=99s fixed for the term of the lease. Anything = beyond that is a matter of contracts outside the technical realm. > This is similar the DNS, it is not as if the registry is free to = change > a DNS delegation at the end of a TTL. This change can only happen for = other > reasons, in particular at the request of a registrar. DNS doesn=E2=80=99t have VALID lifetimes, only Preferred ones. There=E2=80= =99s no ability to say =E2=80=9CYou should make sure this is still correct after 900 = seconds, but if you can=E2=80=99t get an answer, you can consider it still workable for the = next 30 days=E2=80=9D. Nonetheless, a domain administrator is absolutely free to change host = data whenever they want. Ideally, in the event of a changing IPv6 address, = the order goes something like this: 1. Add new address to interface on host, test routing and = services. 2. Add AAAA record for a different name to DNS, more = testing. 3. Remove different name configuration from host and DNS, = make sure new address answers to expected name in expected = ways. 4. Add AAAA record for new address to DNS with very short = TTL. 5. Shorten TTL on old AAAA record. 6. More testing, make sure both addresses are working. 7. Remove old AAAA record. More testing 8. Apply normal TTL to new AAAA record. At any point where testing fails in a production-effecting way, there = are rational and quickly implementable rollbacks. At the end of your contract with the registry, they are certainly free = to change the information if you don=E2=80=99t renew. They=E2=80=99re also free to = change the information whether you like it or not if they are presented a proper law = enforcement document. Example: http://weleakinfo.com Like it or not, I bet there=E2=80=99s language in your contract that = allows your ISP to change your address in case of operational need or basically if it suits = them. Read the fine print. This doesn=E2=80=99t necessarily mean that they=E2=80=99re likely to do = so (probably not, since it=E2=80=99s a pain for them and causes customer unhappiness), but = unless their lawyers are morons, it=E2=80=99s in the contract as a safety net for them. >> I never said that the issue was external communication. If your >> internet connection goes down long enough to time out your DHCP >> lease, Id think that renumbering your LAN would be among the least >> of your concerns. >=20 > No. an ISPs, short DHCP leases are preferred. The reason is that when = people > swap out CPEs, sometimes the old lease is stuck to the old CPE and the = new one > gets a lease only when the old one expires. Short leases are an IPv4 term. Please, let=E2=80=99s talk about valid = and preferred lifetimes in IPv6 IA_PD delegations. The former should be relatively short, but = the longer should be at least as long as the contract. If you swap out CPE, = whatever authentication method is being used (RADIUS, whatever) should be able to recognize that it=E2=80=99s OK to issue the same IA_PD to the new CPE = since it=E2=80=99s still your end site. Now, the IA_NA is an entirely different matter and may well change = (heck, I=E2=80=99d argue even should change) for the new CPE, but you don=E2=80=99t really care = about that for the most part. In fact, that is useful to you if you think about = it. Again, IPv6 !=3D IPv4 I confess I fell into the convenience of using older terminology earlier = which may have contributed to this misperception. >> Nor did I say that they should. In general, an ISP using DHCP to >> hand out fixed prefixes should be choosing pretty long lease times >> (on the order of weeks if not a month or more, ideally something >> approximating the length of time for which youve paid). >=20 > 2 hours is not pretty long in my book. This is reality. Not some sort = of ideal > case. Nor mine. Again, as far as I=E2=80=99m concerned, the IA_PD valid = lifetime should be something approximating the contract length at least. Preferred lifetime = is an entirely different matter. But guess what, a host which has a valid = prefix that is no longer preferred and no preferred prefixes is perfectly free to = use the valid prefix until it gets a preferred one. >> In such a case, your local connections wont break for many days >> after youve lost your internet connection. > 2 hours is not many days in my book. Again, we weren=E2=80=99t talking about two hours. An ISP doing fixed = IA_PDs with a two hour valid lifetime has it=E2=80=99s head squarely planted in the = wrong end of its collective anatomy. >> Yeah, Im not convinced that benefiting your corner case exceeds >> the likely harm when $END_USER who doesnt know what those timers >> really mean starts playing games. >=20 > Of course a RFC should know better than an operator, even when that = operator=20 > is called 'user'. That's the right attitude to get IPv6 adopted. Are you assuming that I=E2=80=99m not an operator? I=E2=80=99ve been an = operator for a very long time and seen a very wide variety of implementations. The bottom line is that = your corner case is just that=E2=80=A6 A rare situation that will benefit a = very small number of end users. OTOH, what is proposed here addresses real world problems = which are affecting large numbers of users today. It=E2=80=99s not so much =E2=80=9CRFC knows better than end user=E2=80=9D = as it=E2=80=99s =E2=80=9Cthe good of the many=E2=80=9D. Owen --Apple-Mail=_23A43AF5-1917-4F88-A8F9-719555086DFC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 10, 2020, at 12:30 , Philip Homburg <pch-v6ops-9@u-1.phicoh.com> wrote:

Call it fixed dynamic address. What does that even mean? It = is dynamic
but never changing?

It is delegated via a dynamic = mechanism, but it is not dynamically
assigned.  It is = fixed in its assignment, yet dynamic in its
delegation.

Thus, on the receiving end, it is still a = dynamic address as the
serving end may decide to change it = at the end of any given lease
period.

If the assignment is fixed, then = the serving end does not change it at the
end of any lease = period. If it does change then that is an operational
error,= because, as said before, the assignment is fixed.

Nope=E2=80=A6= It=E2=80=99s fixed for the term of the lease. Anything beyond that is a = matter
of contracts outside the technical realm.

This is similar the DNS, it is not as if the = registry is free to change
a DNS delegation at the end of = a TTL. This change can only happen for other
reasons, in = particular at the request of a registrar.

DNS = doesn=E2=80=99t have VALID lifetimes, only Preferred ones. There=E2=80=99s= no ability to
say =E2=80=9CYou should make sure this is still = correct after 900 seconds, but if you
can=E2=80=99t get an = answer, you can consider it still workable for the next 30 = days=E2=80=9D.

Nonetheless, a domain = administrator is absolutely free to change host data
whenever = they want. Ideally, in the event of a changing IPv6 address, = the
order goes something like this:

1. Add new address to interface on = host, test routing and services.
2. Add AAAA record for a different = name to DNS, more testing.
3. Remove different name = configuration from host and DNS, make
= sure new address answers to expected name in expected = ways.
= 4. = Add AAAA record for new address to DNS with very short = TTL.
= 5. = Shorten TTL on old AAAA record.
6. More = testing, make sure both addresses are working.
7. Remove = old AAAA record. More testing
8. Apply normal TTL to new AAAA = record.

At any point where testing = fails in a production-effecting way, there are
rational and = quickly implementable rollbacks.

At = the end of your contract with the registry, they are certainly free to = change
the information if you don=E2=80=99t renew. They=E2=80=99= re also free to change the information
whether you like it or = not if they are presented a proper law = enforcement
document.


Like it or not, I bet there=E2=80=99s language in = your contract that allows your ISP to
change your address in = case of operational need or basically if it suits them.
Read = the fine print.

This doesn=E2=80=99t = necessarily mean that they=E2=80=99re likely to do so (probably not, = since
it=E2=80=99s a pain for them and causes customer = unhappiness), but unless their lawyers
are morons, it=E2=80=99s = in the contract as a safety net for them.

I never = said that the issue was external communication. If your
internet connection goes down long enough to time out your = DHCP
lease, Id think that renumbering your LAN would be = among the least
of your concerns.

No. an ISPs, short DHCP leases = are preferred. The reason is that when people
swap out = CPEs, sometimes the old lease is stuck to the old CPE and the new one
gets a lease only when the old one expires.

Short = leases are an IPv4 term. Please, let=E2=80=99s talk about valid and = preferred lifetimes
in IPv6 IA_PD delegations. The former = should be relatively short, but the longer
should be at least = as long as the contract. If you swap out CPE, = whatever
authentication method is being used (RADIUS, = whatever) should be able to
recognize that it=E2=80=99s OK to = issue the same IA_PD to the new CPE since it=E2=80=99s
still = your end site.

Now, the IA_NA is an = entirely different matter and may well change (heck, I=E2=80=99d = argue
even should change) for the new CPE, but you don=E2=80=99t= really care about that
for the most part.  In fact, that = is useful to you if you think about it.

Again, IPv6 !=3D IPv4

I confess I fell into the convenience of using = older terminology earlier which
may have contributed to this = misperception.

Nor did I say that they should. In general, an = ISP using DHCP to
hand out fixed prefixes should be = choosing pretty long lease times
(on the order of weeks if = not a month or more, ideally something
approximating the = length of time for which youve paid).

2 hours is not pretty long in my book. This is reality. Not = some sort of ideal
case.

Nor mine. = Again, as far as I=E2=80=99m concerned, the IA_PD valid lifetime should = be
something approximating the contract length at least. = Preferred lifetime is an
entirely different matter. But guess = what, a host which has a valid prefix that
is no longer = preferred and no preferred prefixes is perfectly free to use = the
valid prefix until it gets a preferred one.

In such = a case, your local connections wont break for many days
after youve lost your internet connection.

2 hours is not many days in my book.

Again, we = weren=E2=80=99t talking about two hours. An ISP doing fixed IA_PDs with = a
two hour valid lifetime has it=E2=80=99s head squarely = planted in the wrong end of its
collective = anatomy.

Yeah, Im not convinced that benefiting your corner case = exceeds
the likely harm when $END_USER who doesnt know = what those timers
really mean starts playing games.

Of course a RFC should know = better than an operator, even when that operator
is = called 'user'. That's the right attitude to get IPv6 adopted.

Are you = assuming that I=E2=80=99m not an operator? I=E2=80=99ve been an operator = for a very long time
and seen a very wide variety of = implementations. The bottom line is that your
corner case is = just that=E2=80=A6 A rare situation that will benefit a very small = number of
end users. OTOH, what is proposed here addresses = real world problems which
are affecting large numbers of users = today.

It=E2=80=99s not so much = =E2=80=9CRFC knows better than end user=E2=80=9D as it=E2=80=99s =E2=80=9C= the good of the many=E2=80=9D.

Owen


= --Apple-Mail=_23A43AF5-1917-4F88-A8F9-719555086DFC-- From nobody Fri Apr 10 13:04:51 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF033A0BE4 for ; Fri, 10 Apr 2020 13:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t46ClRHC1dGW for ; Fri, 10 Apr 2020 13:04:43 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196E33A0BCE for ; Fri, 10 Apr 2020 13:04:42 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 BE04A80238; Fri, 10 Apr 2020 22:04:35 +0200 (CEST) To: Philip Homburg , v6ops@ietf.org References: <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> From: Fernando Gont Message-ID: Date: Fri, 10 Apr 2020 16:56:08 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 20:04:51 -0000 On 10/4/20 16:38, Philip Homburg wrote: >> If we modify the IPv6 protocols to accommodate ephemeral addressing, >> then there is no incentive for operators to offer anything else. > > This is something the market will solve if we won't. > > It is already years ago that AVM FRITZ!Box had a misfeature that it would > try to deprecate prefixes it didn't hand out itself. > > I can imagine plenty of hacks that can 'solve' this problem while creating > lots of others. RAs at a high frequency were already mentioned. Couldn't agree more! Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Apr 10 13:57:47 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF783A0D35 for ; Fri, 10 Apr 2020 13:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9VT7HBvV24L for ; Fri, 10 Apr 2020 13:57:44 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913AF3A0D34 for ; Fri, 10 Apr 2020 13:57:44 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id b8so1508954pfp.8 for ; Fri, 10 Apr 2020 13:57:44 -0700 (PDT) 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=FwWllnIlWMY2ympkLkMCt3SgmjcOuurK5/nHyr3eMM8=; b=nB9Y6UyH32JFalQ8KUaMotdOQdJElioUHnwouzOvfkXDsuzh8Y1tzX+/tPQiz1c5WQ 7ok3103c0TofhfEm0gYIx7bKtm0FWjsXvxMKTC1RC9maoDMwzid/wDkbCPZat9rao1in +p8NAh/amGN41Iw4ij23LZXwEIIJRQwk3MUS72/F58pUKsE1NcxgthaHMlTphSx0DyfN vUcH3L9UAo2qZk0hZoTY1BruS6TZ+p+lVx5MgdRbCTpmccQ8vO/43wwhQAj+mhWplGgD /f92dvPUwiyQzP9thTU+Yggodf7REAKIXhGmWxqvJChsHp2wOIMnp8xvjgl3BXdewcOZ /X7g== 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=FwWllnIlWMY2ympkLkMCt3SgmjcOuurK5/nHyr3eMM8=; b=TE2SB+dTmsACf4yGGSYhV1FW+GF1GbL8CIKjJPXHVq/v0U5qtPcMY1TBQgTWf6gIuQ O7A65VGCOdGeWSobBsTXU6nlp7rOJ4T+gvcfhH3SCqiiMQ9rdGwRmwhh81jHUjYzAhxO t1idq9j/dhWg+FfOSRxPHUQH0pi8EDxr9n3w8n9UejymKulx/LCaCjvlDq3RCqZuBMkn MGCmSHn89rmJiLVqc+E9xigJpxe0SviKRIBdq4dNb6rQ2q482DNr7L87wP+XzdIWRzd3 xL6uBvXasc5gSPmkSd6W+wQvu2jAognq/VUK0WkCHjJLqL35b5p7H8qu5bzYO9X8HQ0g Fw5w== X-Gm-Message-State: AGi0Pub8aMqffW5rzcZp9+y/6mLU9qokZUb6e2AFjLeQlND691FxObXy +ybvroavasYhq1ub2UV/J22a2rXz X-Google-Smtp-Source: APiQypINknzkR1zcL4u3ud8PVV1b+w7iqC+BzI2tdjj+vTTEivQRTJTCocIXz08Zpm51cTcTWNY5Pg== X-Received: by 2002:a63:8c51:: with SMTP id q17mr6360479pgn.320.1586552263825; Fri, 10 Apr 2020 13:57:43 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id h11sm2507924pfn.125.2020.04.10.13.57.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2020 13:57:43 -0700 (PDT) To: Gert Doering Cc: v6ops@ietf.org References: <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> <20200410160231.GM50230@Space.Net> From: Brian E Carpenter Message-ID: <49da8a30-e687-089e-2bb6-41691f0bb0bc@gmail.com> Date: Sat, 11 Apr 2020 08:57:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200410160231.GM50230@Space.Net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2020 20:57:46 -0000 On 11-Apr-20 04:02, Gert Doering wrote: ... > Actually, applications that can deal with "oops, my hosts's address changed > behind my back, so what" are something we need to see - devices are mobile, > roam between LAN and wifi and LTE, addresses change all the time, and > users expect things like audio/video streams to continue seamlessly. This can't be said often enough. Apps that can't deal with unexpected and unannounced address changes are simply broken. Yes, it may take a little time for them to notice and correct the situation; the user may notice a glitch. What we do here can reduce the glitches, and that's a good thing. But don't aim for perfection, because it's impossible. Brian From nobody Sun Apr 12 04:35:09 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05003A218C for ; Sun, 12 Apr 2020 04:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKuf4hv3cyuk for ; Sun, 12 Apr 2020 04:35:04 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53FAC3A217A for ; Sun, 12 Apr 2020 04:35:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id DCF1298; Fri, 10 Apr 2020 17:15:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1586531757; bh=7QIj4GWop1cV1QNAnB0 a0FPEJEWaDIwGjuQFFtG9gPE=; b=RXbh5Re/K1Ttkqkp0sBR4ofUL4QXtdDg1wo dJybLrUxFLkDqcg6RfBQUUiID32XECjApzjKHfsdTYZ2+lCMLGdlSo5os/ZHEJZ5 rdIe7fyNLwkAWM5T0GDfhwwspAl20ur01aPRKM1r7ICocwTbbcpyZ5M3QqiE4VVL NFF+XwWM= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JnR_CepcLCOT; Fri, 10 Apr 2020 17:15:57 +0200 (CEST) Received: from [IPv6:2a02:a213:a300:ce80:3016:be52:6c6a:f822] (unknown [IPv6:2a02:a213:a300:ce80:3016:be52:6c6a:f822]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id A0FA064; Fri, 10 Apr 2020 17:15:57 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <6A8DBEC3-198F-4C20-A223-2F6E76F4B639@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_07EA5F60-C372-4990-A69C-C16A3E47D1D5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Date: Fri, 10 Apr 2020 17:15:56 +0200 In-Reply-To: Cc: Ole Troan , v6ops@ietf.org To: Owen Delong References: <38B4C8F7-E534-4E64-9164-8C65DCABB3BA@employees.org> X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Apr 2020 11:35:08 -0000 --Apple-Mail=_07EA5F60-C372-4990-A69C-C16A3E47D1D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > However, this still hinges on the assumption that ISPs will behave in = the manner you describe. I remain unconvinced that will be the case. This And refusing to help those whose ISP doesn't behave like you would like = them to is making it even worse. This WG needs to grow up and realise = that we don't live in a perfect world. We should work towards making it = better for the users, not shunning those whose ISP doesn't confirm to = our dreams. The internet is a for-profit system these days, and despite how much I = dislike it, we need to provide incentives for ISPs to do things the = right way. Hurting the poor users who don't have any = knowledge/choice/etc is the wrong way to do that. Same as with the = Android DHCPv6 disaster: it's hurting the wrong people. We need to work = on standards and tools to make it better, not making it worse for those = who cannot help it. Cheers, Sander --Apple-Mail=_07EA5F60-C372-4990-A69C-C16A3E47D1D5 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----- iQIzBAEBCAAdFiEEl13OIanoifT0p8LWWPjdc9pon8sFAl6QjawACgkQWPjdc9po n8u6XRAAnO5xjo+jwMnakx30gvtLjkZiEcykoXzWUt+ehcwoobhMoPo12WEmB11c iwoBtyFDSSYOFYrVOioo+Zt+O+ZY5x5sp7oamMBHei9+NxRymAFOL1d+xoxpN6X+ H/uWLKRH+h7Z/miNZ0W6Fs0UvNbd2aqQIjdkG+s6zoYzqYuBa0dh7wUXTP6S7x/W 8/GCjqT0yQ8baczRMrTYVzFHHE552BQZ1NLpbHD9LXA5Qp9YFjm4qVgNUh7oyjGb qt6IcVdSAnWCsn/RuM4Eb5hJs2lOOEYOtvdopW8ehLj8aV1lXcpmF6uytEKeES83 g62T2c5GaYxgSkfzuwuxOhcIv3+22ScKp8WUF85NFInUAHGwWFtpUdsbrCyihLO3 +Cj1AL1oI38Rrx9o0tlur2E81IY65M536SB2rXtY/vubAgkZHSZggtkDvNuWcpOn FV0F24T32uD89axN197S2XzA35812H19ZIkkP6ce9D+aJa2X1yiGExkZ7PA4E3cH a6gQDr//xWUsr8BFVrGJ0LnnvY6e962dZ+QiWnJwZUEAlTXRDYYxWkpsuq59p3tf feezKzX2uDvjYdrXvvhcocPeUDS3bpyX7HZO9g0Vqp2jLlSuoCJoq3ZXLiBXVm84 fgnU2FwLSMvbvmt3Bka028AC9cDJ3SsS9aeNztlp8SOIDw+ra4Q= =F7U0 -----END PGP SIGNATURE----- --Apple-Mail=_07EA5F60-C372-4990-A69C-C16A3E47D1D5-- From nobody Sun Apr 12 20:09:34 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272533A0BA8 for ; Sun, 12 Apr 2020 20:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-HNV8vmIZxM for ; Sun, 12 Apr 2020 20:09:30 -0700 (PDT) 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 D23AC3A0BA7 for ; Sun, 12 Apr 2020 20:09:29 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id 60so7825008otl.12 for ; Sun, 12 Apr 2020 20:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/g15qhBibnQ7HPBjf7a02lpAGl46KvykZ9OnZ2x9mZs=; b=McL/hLCh53E5BiiuydJGSt6bl5bqMEhwIfs+MXMSy/tWVG0PWxi+rEnpJA7hpH0FB/ GjlzlERO4T/aORXxE6exINByY3Vo0iBOnspNiaGMQePZLXZh7UaLrKmiHUaw1li7OSJg g1xmQ4418gUt4q/4TvJZCvq/6JzlfGunoMp6l1rwfJyQTf+wZTphn2sTn1YEeBfFhSKk rQpqsCOq75KCNUwS4UmAXmUOKobCONGS7NTtx04QFFr8L8S3kA9gYsvVyAjxApn+cR1r i07GvG+TeZJWZAvD+RnLVOCvVuBsxQDmtzKxAxjyvavul5FyeMWXUJjlFZXxezFulq/Z CmOw== 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=/g15qhBibnQ7HPBjf7a02lpAGl46KvykZ9OnZ2x9mZs=; b=m0vPq9V0kGV/WuotUFM322UuRb4Y6ctq67wSCcQnqBdEDuLcQ39ZsRBG9zivNVjw1Y 5ZMB7eUoloe9tyedP5wKkwe1dejsUYGCXVXdPEOhBNkG1mJPcnk0lbqovmZqVtHhnZxm sQ4nKcpIsiC33NubPXxNX0wE/dlrTq6e/x/rUmJ2paXKoSKppEtWDyYtw/cQ6vs+7zoE wIYkVmJPFOuy4Mcn0g553JyAMF6s6HNVY+qIMCxeW7Zz1JTr1g1O57WlB/LRAXFHrsxx urYB2e8vULmzS888S6Z3tfnaYiE/2cc//5E//fTZ7UrJ5LT4qRbABw3o4sYOEF/sRh/p WCiA== X-Gm-Message-State: AGi0PuaeHsj7hSeFE87Xi+Q6PVPKPCvOS9Eeo1D6KlHmtb4zdTY/SO/c KxS5iWS5dvk00PO1lQBTrB2VQmj5ymvfGOIXXIQ= X-Google-Smtp-Source: APiQypKaGtI0+1WVzF/GCcXEbwq95sLFOKOQEzd6IPkrC4Z0EtuvVRZeUIhDjXYqjKh4tO/9ag5xPHonrl6ppewflU4= X-Received: by 2002:a9d:62c2:: with SMTP id z2mr13660893otk.155.1586747368942; Sun, 12 Apr 2020 20:09:28 -0700 (PDT) MIME-Version: 1.0 References: <716E84F8-5B39-4CAD-B617-06CC1663BF9D@fugue.com> In-Reply-To: <716E84F8-5B39-4CAD-B617-06CC1663BF9D@fugue.com> From: Erik Kline Date: Sun, 12 Apr 2020 20:09:16 -0700 Message-ID: To: Ted Lemon Cc: Fernando Gont , IPv6 Operations Content-Type: multipart/alternative; boundary="000000000000462ed805a323693d" Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Apr 2020 03:09:32 -0000 --000000000000462ed805a323693d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Were slaac-renum and cpe-slaac-renum originally the same document but a recommendation was made to split them? If not, I personally don't see a problem with one ops document that both describes the problem and provides operational recommendations that could help ameliorate the issue. But if a doc split was recommended I certainly don't want to reopen that discussion. On Wed, Apr 8, 2020 at 6:10 PM Ted Lemon wrote: > You=E2=80=99re right about the two-cpe case. > > Sent from my iPad > > > On Apr 8, 2020, at 8:58 PM, Fernando Gont wrote= : > > > > =EF=BB=BFOn 8/4/20 20:33, Ted Lemon wrote: > >> I agree with your analysis about ICMPv6=E2=80=94thanks for that. I th= ink that > the source address selection solution can work, though=E2=80=94it just re= quires a > slightly more clever algorithm than the one you proposed and then > rejected. I described it in another message. > > > > FWIW, to be honest, the one described in the document had been proposed > by Jen. So that's "the only one" that had been discussed, and hence made = it > into the appendix. > > > > > >> One thing that could be done with source address selection is that if > an address fails the test I described (choose the loser only if its > preferred lifetime is ten minutes longer than the incumbent), you could > send a router solicit for the router that advertised that prefix; if > there=E2=80=99s no response to the solicit, then deprecate the prefix, an= d when > there are no more references to any address on the prefix, gc any remaini= ng > addresses on that prefix and the prefix itself. > > > > I will dig and try to find the specific message. Or, if you know which > one it is, please do fwd to me. > > > > There are two things to note here: > > THe problem with comparing lifetimes is that: > > 1) In order to be able to compare two PIOs from e.g. two different CPES= , > you depend on both of them capping the PIO lifetimes (for the lifetimes t= o > be comparable). And then you also need the host-side update. > > > > This means that if update the host (simple, and doable in a timely > manner) but are not employing updated CPEs, the mitigation doesn't work. > (If I'm understanding it correctly). > > > > OTOH, the algorithms from Section 4.5 of the draft only require > host-side changes. As long as you implement them at the host, you already > received the benefits. > > > > > > In particular, the algorithm from section 4.5.1 is really > striaghtforward: > > > > * Upon receipt of an RA that advertises new prefixes but not the > previous one, you deprecate (un-prefer) the prefix/address (the I-D says = to > actually set the PL to a couple of seconds to accommodate the thoretical > case where the information might be split into multiple RAs.. but in > practice you wouldn't even need to wait at all). And you also set the Val= id > Lifetime to a value in the order one or a few dozen minutes (so, if > meanwhile you receive an RA advertising the prefix, the addresses get > refreshed... and otherwise, after that time has elapsed, you'd > remove/invalidate them). > > > > > > IN the typical case where e.g. the CPE crashes and reboots, as soon as > the CPE has bootstrapped, the first initial RA will provve both a new > prefix, but also deprecate (unprefer) the previous one. SO the only waiti= ng > time would be the dozen minutes or so for the address to be invalidated. > > > > Of course, you could even augment this, and instead of passively waitin= g > for a dozen minutes, you could send an RS after 5 minutes or so. But, > unless I'm missing something, there wouldn't seem much to be gained. > > > > > > FWIW, I see RFC6724 as doing the right thing. IMO the problem is that i= n > current implementations, the preferred/deprecated "implict flag" is > severely broken: the use og insanely long lifetimes really means that you > don't really keep track of whether adresses are preferred or not: for all > meaningul purposes all addresses are considered "preferred" (well, except > the temporary addresses that you phase out) > > > > > > If I have misunderstood your algorithm, please do let me know -- we're > not married with any specific value, and meant to do the best we can. > > > > Thanks! > > > > Cheers, > > -- > > Fernando Gont > > SI6 Networks > > e-mail: fgont@si6networks.com > > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000462ed805a323693d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Were slaac-renum and cpe-slaac-renum originally the same d= ocument but a recommendation was made to split them?

If = not, I personally don't see a problem with one ops document that both d= escribes=C2=A0the problem and provides operational recommendations that cou= ld help ameliorate the issue.

But if a doc split= =C2=A0was recommended I certainly don't want to reopen that discussion.=

On Wed, Apr 8, 2020 at 6:10 PM Ted Lemon <mellon@fugue.com> wrote:
You=E2=80=99re right about the two-cpe case.
Sent from my iPad

> On Apr 8, 2020, at 8:58 PM, Fernando Gont <fgont@si6networks.com> wrote:
>
> =EF=BB=BFOn 8/4/20 20:33, Ted Lemon wrote:
>> I agree with your analysis about ICMPv6=E2=80=94thanks for that.= =C2=A0 I think that the source address selection solution can work, though= =E2=80=94it just requires a slightly more clever algorithm than the one you= proposed and then rejected.=C2=A0 I described it in another message.
>
> FWIW, to be honest, the one described in the document had been propose= d by Jen. So that's "the only one" that had been discussed, a= nd hence made it into the appendix.
>
>
>> One thing that could be done with source address selection is that= if an address fails the test I described (choose the loser only if its pre= ferred lifetime is ten minutes longer than the incumbent), you could send a= router solicit for the router that advertised that prefix; if there=E2=80= =99s no response to the solicit, then deprecate the prefix, and when there = are no more references to any address on the prefix, gc any remaining addre= sses on that prefix and the prefix itself.
>
> I will dig and try to find the specific message. Or, if you know which= one it is, please do fwd to me.
>
> There are two things to note here:
> THe problem with comparing lifetimes is that:
> 1) In order to be able to compare two PIOs from e.g. two different CPE= S, you depend on both of them capping the PIO lifetimes (for the lifetimes = to be comparable). And then you also need the host-side update.
>
> This means that if update the host (simple, and doable in a timely man= ner) but are not employing updated CPEs, the mitigation doesn't work. (= If I'm understanding it correctly).
>
> OTOH, the algorithms from Section 4.5 of the draft only require host-s= ide changes. As long as you implement them at the host, you already receive= d the benefits.
>
>
> In particular, the algorithm from section 4.5.1 is really striaghtforw= ard:
>
> * Upon receipt of an RA that advertises new prefixes but not the previ= ous one, you deprecate (un-prefer) the prefix/address (the I-D says to actu= ally set the PL to a couple of seconds to accommodate the thoretical case w= here the information might be split into multiple RAs.. but in practice you= wouldn't even need to wait at all). And you also set the Valid Lifetim= e to a value in the order one or a few dozen minutes (so, if meanwhile you = receive an RA advertising the prefix, the addresses get refreshed... and ot= herwise, after that time has elapsed, you'd remove/invalidate them). >
>
> IN the typical case where e.g. the CPE crashes and reboots, as soon as= the CPE has bootstrapped, the first initial RA will provve both a new pref= ix, but also deprecate (unprefer) the previous one. SO the only waiting tim= e would be the dozen minutes or so for the address to be invalidated.
>
> Of course, you could even augment this, and instead of passively waiti= ng for a dozen minutes, you could send an RS after 5 minutes or so. But, un= less I'm missing something, there wouldn't seem much to be gained.<= br> >
>
> FWIW, I see RFC6724 as doing the right thing. IMO the problem is that = in current implementations, the preferred/deprecated "implict flag&quo= t; is severely broken: the use og insanely long lifetimes really means that= you don't really keep track of whether adresses are preferred or not: = for all meaningul purposes all addresses are considered "preferred&quo= t; (well, except the temporary addresses that you phase out)
>
>
> If I have misunderstood your algorithm, please do let me know -- we= 9;re not married with any specific value, and meant to do the best we can.<= br> >
> Thanks!
>
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgo= nt@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
--000000000000462ed805a323693d-- From nobody Sun Apr 12 20:46:38 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BA93A0CD4 for ; Sun, 12 Apr 2020 20:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvchBC8sH8Mi for ; Sun, 12 Apr 2020 20:46:34 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A173A0CD3 for ; Sun, 12 Apr 2020 20:46:33 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.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 5F463808B8; Mon, 13 Apr 2020 05:46:30 +0200 (CEST) To: Erik Kline , Ted Lemon Cc: IPv6 Operations References: <716E84F8-5B39-4CAD-B617-06CC1663BF9D@fugue.com> From: Fernando Gont Message-ID: <9047b3c9-55e5-3c54-4616-a9b27dc3ac85@si6networks.com> Date: Mon, 13 Apr 2020 00:46:18 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Apr 2020 03:46:37 -0000 Hello, Erik, On 13/4/20 00:09, Erik Kline wrote: > Were slaac-renum and cpe-slaac-renum originally the same document but a > recommendation was made to split them? Yes, exactly. Originally it was a single document. Subsequently, upon suggestion of multiple wg participants, we were asked to split it into three: * draft-ietf-v6ops-slaac-renum: Problem statement and operational mitigations. * draft-ietf-vops-cpe-slaac-renum: CE Router reqs. * draft-gont-6man-slaac-renum: Protocol updates. [..] > > But if a doc split was recommended I certainly don't want to reopen that > discussion. Yep, it was recommended. And a number of folks (Jen at others) were happy with the split. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 13 08:43:44 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C787D3A1854 for ; Mon, 13 Apr 2020 08:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=hcdj4Y63; dkim=pass (1024-bit key) header.d=juniper.net header.b=auyz010S Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGrweVovepDz for ; Mon, 13 Apr 2020 08:43:41 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 A73763A184D for ; Mon, 13 Apr 2020 08:43:41 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03DFg3VS028636 for ; Mon, 13 Apr 2020 08:43:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=4Mea9gg8BBjV+QIm/9whBl/zgy5mrTe54oSorfB0TBk=; b=hcdj4Y63Tv1ZrMWmVNRARrJMypmGB7qGc4MvDI2L+TVNIlLOsnlRUl6WCSsmy4Pe3oBl Ac8DRy3WsYRGvebKlVJrd5Yv4BK/BamXpmt9nIDyaZm4Kw+GEQHFBX9Sno/rIarUIhGb Z1QHQ3Aqk5H7KsOzvtu6U07hDki9s/p2uQ0iX7icBKs60w/Kj4+z4PvEjlNd3EYiwPnR k+/3HXBbgxzv0CGKRHV/MeuPfsA0ut35wm4cXz1XIXjcONPSx/5ZKEJbOROmIdrP4QSR o/dNw2mbUxMB4oZ+lrgJM8Vh2Nl4Zk5qhJKXv05m0cMqiGyZ36WuBB08U3i3LCcCPV1G KQ== Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2058.outbound.protection.outlook.com [104.47.37.58]) by mx0b-00273201.pphosted.com with ESMTP id 30bd0xtkej-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 13 Apr 2020 08:43:40 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fyOx4LDmNEiPj08VsLEgaUQQiDlYEnwToUdyYyvEZ5ptb/8uWH8OgJGEX6okUwnz4jMWLBJn7AFrDt/qzmq57Yc/lncaltx9b1ZyR2+c5lhspMiZsIZJDnmZ+DdJGwLfIFnXV/Jsiz1Z/aDc4SBj4BuM+IoFFLG8ZuT0tV5TEUmSQvTOM1Sli/Zri6pBU1nYYhWEIFDfaZukQbtnVb7tDPWYKLr0FFZcWSf6U3XqiTQhQ+AXXCQJeaWFpdkSt3n0AP+QOfxPtnAv/gYNjbe78xorXv6H1ZDAA3aSpuhUZKRPhxUelj6uIjPUNx8a4gUVthMof1OT5sWo/r1r7/PPTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4Mea9gg8BBjV+QIm/9whBl/zgy5mrTe54oSorfB0TBk=; b=Wxl0ytGGn0DaYE6vjqOtogkTOcO94C0+skv5/TyzdnzqLKT6Wo0xqXMVOyQfos/Oz12r9g19BC0vzBNvm1bJB7uDfUomAXJ4RvfMN4ZGTrabrBJ4nePYHliquVAga13A0MKs+hnu/afm+J+Ydqk+UhlbVsCFjNrtsZgiZUvgH7YckO5k6kPYe1ODKNL8gXskVXOzzv86iRui+Khk9qgaGFUjCmoLQJCp2wh82mMWoLyufP7M3TwIwYcMwEQwG0/zXnxNONecCO34ueZx/Dqh4aADZxnZLHFTTCIiN9fDD+0SHW433i0Zc712sG6iCQsBdtJox9pm2G/2AkIE04lyVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4Mea9gg8BBjV+QIm/9whBl/zgy5mrTe54oSorfB0TBk=; b=auyz010SvPKlR8vUOkwGgwEwBGD+cUmDcldkLPYFZgEyd4hzXHF8WWQ0PW1GKi871PnqBbdIPuEhuRaYToXxlmYDo37NceRnALabhKt/NiOktAK6osyWvWw+bPpN/o55idwBB1dQkr8YoU6O+ngyeLLH6PCoCkXxMiSSLfCf5z4= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB5177.namprd05.prod.outlook.com (2603:10b6:5:79::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.18; Mon, 13 Apr 2020 15:43:38 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3%4]) with mapi id 15.20.2921.024; Mon, 13 Apr 2020 15:43:38 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: Working Group Last Call draft-ietf-v6ops-slaac-renum Thread-Index: AQHWEamt9NL+Sr5JBkGOoGKwEa6s5Kh3MVkQ Date: Mon, 13 Apr 2020 15:43:38 +0000 Message-ID: References: <202004131539.03DFd08A043411@svl-junos-d082.juniper.net> In-Reply-To: <202004131539.03DFd08A043411@svl-junos-d082.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-04-13T15:44:29.0994284Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=318f8086-418c-4d7f-a260-1265a9221678; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8e75535b-4ef7-4553-3a47-08d7dfc16f65 x-ms-traffictypediagnostic: DM6PR05MB5177: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2089; x-forefront-prvs: 037291602B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(346002)(136003)(376002)(396003)(366004)(39860400002)(86362001)(6916009)(66446008)(186003)(76116006)(66556008)(66476007)(64756008)(9686003)(66946007)(6506007)(7696005)(55016002)(478600001)(81156014)(52536014)(26005)(33656002)(558084003)(8936002)(71200400001)(2906002)(8676002)(316002)(5660300002); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OhFScJNLXWGDnrR7+8zxHUxqa4IMKKhX4nM8WLwy6QkT5zX1MELYo4rBp3+M8Fk5iWLdESMiy35sL2Q8EJLb/wiJ/MszFMatNNyvxRDUQUK2FV2sr1nTZfjPijf1wsNOyvCynnCGUeR06Vm8Cx1prXKGMuT0cY+i5eukjIUgQM4aR3+Gw7tCTB1FIEB6AYtec3yIbmhd4aQewzDfb3aYB9wdq3lbtk3d48aQUaSFTxWJAD2ksW6M3tqSkOq6fHxZIBYqAy/FnFk/feShfh5Ztaldh4+4qqqq7e+hS5UAVrgxYnYbWYrePR3N9spxOYFvTT500g8O/SxXVjBYgL11BRsGuk+wcWbv/D1iSpb5nQaj2aAywXxD8UKNcNRF17spEYqnduqwaaiW0qH74HbXk0SCwzhk/Gk4Uiu/uwWcsln6GmCSo28CzgQE32d0dZlA x-ms-exchange-antispam-messagedata: YbHb/8f+ACodn8zx0Ju+NQEVD3LfEtJpgrlyRNuHGZUeD/SJ/8cFQNnDoHdWFusBtQgOJccLPsfvFZLBMuOYg0hXmT9EEOu4osY1AkwHu9DgCRoDWKfr+FlkAMfB3JC96mcBXKDjd/LHtULOyapx7A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 8e75535b-4ef7-4553-3a47-08d7dfc16f65 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2020 15:43:38.5442 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nikb5cMJLvvRnlRlkN8eed2dtUQCkT3grNJ4QViNu3NY0UgUhByusiYXCow6B4JY2+rHCkNJz+txGSbPQuwTeA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5177 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-13_07:2020-04-13, 2020-04-13 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 spamscore=0 priorityscore=1501 mlxscore=0 phishscore=0 adultscore=0 suspectscore=0 clxscore=1015 mlxlogscore=506 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004130119 Archived-At: Subject: [v6ops] Working Group Last Call draft-ietf-v6ops-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Apr 2020 15:43:43 -0000 Folks, =20 This message initiates a WG Last Call on draft-ietf-v6ops-slaac-renum. Please submit comments by April 27, 2020. Fred and Ron Juniper Business Use Only From nobody Mon Apr 13 12:08:06 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A60A3A1C4E for ; Mon, 13 Apr 2020 12:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaYQOItvceu8 for ; Mon, 13 Apr 2020 12:08:03 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0703A1C4D for ; Mon, 13 Apr 2020 12:08:02 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id a201so10730580wme.1 for ; Mon, 13 Apr 2020 12:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ilVJxE8R6i9qmaV4KaWaIrxWXSPj7X4Y2jcUxVwuPOE=; b=EnnBhCxZDhGS4Mtq/g5A5Mgm6ttJJsgDJcOtEPOWuhijSE6Xn/txUqBmdK4FtBGmAo i4kF4SiGl92UqIPIiiHykHpl9FdbrRHji8bsms+rD5u2UCdvB7PMHYjrorSVUflKV185 LWDZyhbgBJO+78xB+X5XBm+7kHzRVhjSyP/z0X4b1UGySsXtioWDMWeUGzQzq2QOhHcy Nk/+5yqmND7cLMlTHDkvjasOr7lLGOgfs+CWtCWfX/xLck2UTBSj9vsHzUKUl6a0YNs0 cW8nppjUHmqn/pOiFAfCBJhHl4PuY4pgxOJVpmuRo4c9TDUPBABzHj7nz4vDHbYH/5RW QSqg== 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=ilVJxE8R6i9qmaV4KaWaIrxWXSPj7X4Y2jcUxVwuPOE=; b=jJ0vV/ne8HzeNyRLyK9M93tbaph9YwFyrj+bFR8ux+xlL7PP6GtNvXbeYimGRYOa7G TmaPdZYsB8RTrh/qJi4JD8lOsakziVmKYMFgwP5fG4VeHkgCY5pm6nFpg+QK0uDBruCL QGpqOpDtKY413qAaxxFDRkOnG7cb0TYK743kMQgDYRFeuCWxN+jdFSIVF6c7t+1KXjWO cJCLA43Lk5Cqw9sBRGI4s2ey23Dx59NCvEQ0ycnGDeFZgYfsewuZSI9xBxlBnhDlmG4B Cd8IffYgs7noTrOSXMqbcduJKvaGBhqDreUx+H0KnTfvfAVNyHxz8VEg+lsifHEYqzKl crxQ== X-Gm-Message-State: AGi0PuZv84lS4I+zRRA6EaVXrAi7ym2rh2YstDszHu0qlVAzcTwM6DuM y31F8XnDsFdKWYF/HeruE2MBdcdt X-Google-Smtp-Source: APiQypKyvDOBT9N2MRiDugl3h92zKCAb8NLDT4WF+HVs7kCotp3in9mKB5WzDVWfdub07/7d6a+rqw== X-Received: by 2002:a7b:c250:: with SMTP id b16mr20744422wmj.100.1586804881205; Mon, 13 Apr 2020 12:08:01 -0700 (PDT) Received: from ?IPv6:2600:8802:5900:13c4::1003? ([2600:8802:5900:13c4::1003]) by smtp.gmail.com with ESMTPSA id 145sm16545361wma.1.2020.04.13.12.07.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2020 12:08:00 -0700 (PDT) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_06F21A95-D2D5-4243-BC66-97AD62F171ED"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 13 Apr 2020 12:07:57 -0700 In-Reply-To: Cc: "v6ops@ietf.org" To: Ron Bonica , =?utf-8?B?SmFuIMW9b3LFvg==?= , Fernando Gont References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Apr 2020 19:08:04 -0000 --Apple-Mail=_06F21A95-D2D5-4243-BC66-97AD62F171ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For the record, this discussion has closed, and Ron sent a note this = morning opening a new WGLC. Fernando has opened a thread in which he is = verifying that changes he is making address the points raised. I expect = he will post a new draft in a week or two. I will query those who = responded in that thread and convince myself that they are happy with = the changes, run a quick WGVLC (working group very last call) on the = list, and then be looking for a draft shepherd as described in IETF = processes. > On Mar 30, 2020, at 8:47 AM, Ron Bonica = wrote: >=20 > Folks, >=20 > This message initiates a WG Last Call on = draft-ietf-v6ops-cpe-slaac-renum. >=20 > Please submit comments by April 13, 2020. >=20 > Fred and Ron >=20 > Juniper Business Use Only > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_06F21A95-D2D5-4243-BC66-97AD62F171ED 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+AFAl6UuI0ACgkQEhdRnd2G P+DgBBAAiRRg5YbOytDSqpsF5F7ohL2gwI12rd0v5pPaT9NZsdHrA/UbO1vTpE2c gG4xNtRKMy4nu2o91oXpkFO8jeWOdsQDjE9heQgsenmDnnQUJ8YffsFW8XXBWdWr Ok83meG+4n18b64u/06R0qjkr+OeeefnfLOjEFenwP0QUyD+925fzdUqvCLuRRWb nq9a1un8x5PZjWgMX3TvQPttd9YP7aWjLfFkD+bw5wtfjtbmMOrf2rQe+Tk8P45z m6hp98feehnCWWy9jb72zC8eykb2Q3SacC7sG+O62FI7qlkGX4z4qyy/YeQU8vTu g8/IrGWUcNcmvVrHaJ+4/Xk3MsoRpkc9cX9P7xhl4EVQ0I64JVOccj5/eOtfip99 6Q7YsdgHn4bUAlu2BWB9MTHvhFN8b8dlKpLfJV4ZVsgPClWY6jAzxvujJDGXrcZg Dcs5YxUc/NK4upohiEPDpGXijL+Iw/IBciuFgsZLZXcdBA51BfZZH6Vui5RCBqtj z+/v7gtE5b78Rk+WfM6n1uBQLT6m1uARg3wc6EKuTavDxSuxTsu76vm8oghRGAFq kbvRWhfA/7urEIsDOCsdEnDCRNvGUJZmPomXciCealckaNc6sJ9Jvq7nMp6lH4b7 R6IS3c4PJxtshHzxUwOQDokbf3JNVuO5xn1wFA8ZlsxC+fQ5k7M= =dsT5 -----END PGP SIGNATURE----- --Apple-Mail=_06F21A95-D2D5-4243-BC66-97AD62F171ED-- From nobody Mon Apr 13 20:28:58 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84393A092D for ; Mon, 13 Apr 2020 20:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 fAUw2tIJXWtf for ; Mon, 13 Apr 2020 20:28:53 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4351E3A0929 for ; Mon, 13 Apr 2020 20:28:52 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 03E3SeZu1317751 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Apr 2020 20:28:41 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 03E3SeZu1317751 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1586834921; bh=acYLwz4k1gfqrMWoUVPp6yeT1KjdelBmlLe3F7p700Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=4cEC0xe6OyQyyT/sG8vrRLl12DFuJtmeVl3K3HsM8ddDfAIaTcaqseLAjtFSvNxOk Pume535Xz9n94dx83C93RLvXSCSK+LRa5wGRfPBmbpSIKR1p2CxIeiwoOGsaP7Vrs3 KZ34cGqQydEWInE5tY4RhUWoGrgyHMTlUd/yqBK0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: Date: Mon, 13 Apr 2020 20:28:40 -0700 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <202004131539.03DFd08A043411@svl-junos-d082.juniper.net> To: Ron Bonica X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Mon, 13 Apr 2020 20:28:41 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Working Group Last Call draft-ietf-v6ops-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Apr 2020 03:28:57 -0000 I support this draft. Owen > On Apr 13, 2020, at 08:43 , Ron Bonica = wrote: >=20 > Folks, >=20 > This message initiates a WG Last Call on draft-ietf-v6ops-slaac-renum. >=20 > Please submit comments by April 27, 2020. >=20 > Fred and Ron >=20 >=20 > Juniper Business Use Only >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Apr 18 12:25:35 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA673A10E2 for ; Sat, 18 Apr 2020 12:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4ZEALmDcno6 for ; Sat, 18 Apr 2020 12:25:32 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC663A10E1 for ; Sat, 18 Apr 2020 12:25:32 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id t16so2342592plo.7 for ; Sat, 18 Apr 2020 12:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:date:subject:message-id :to; bh=mD+/jCeiP8Cvan/MvQL9munHuFn/DfPZxJlPDgJ/j2Q=; b=CLVY2bLLCOAyVHQlY7RkxnNMoJNzSpkRsD9QUIDk2RNigkF7NEwlq5Xpue8LlgHyYb XdPPbpD5Cm/oqqBqr63HOlZxr2Q+nex8Hpv3LYBFAXij0q5RNt4ppMP3K07RYOuq14Lz 0K3FjcuqAkWhbDLuWHX6eImVp+3EhGvj/xf5GOIIa59ceRi6SYknla9C8S2LJdYhTEB8 TleqlzmvmeqN0gtWXUNqRgKmE629y1zpGIA+v0KHNYWPDyxXzWod3B3w8e8c+usA1nKo RwW+ViQwyRrHksI/fw0HovdkjXrLDv6ch9LeKfRlmMwTSpsuHfuisE6lIQlgiPT/AjwX nKPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:to; bh=mD+/jCeiP8Cvan/MvQL9munHuFn/DfPZxJlPDgJ/j2Q=; b=aRG8Y9jR4LSAwbWyzfZhv6l4zh5txXYYzRnqbOQ2h39O0r+LCTjSoMDklpqSgmWPJ9 tyxnjfLnMaM2C4PqXntF5TlGG+p5+3GdK45UrfGuVHu2Hhhvw/432b/uWZRqK3URT2Ne ZEVMfFLMr4aqWojitH66dKp9N/zLH3IEE5VeKQkNYm8KnVD8Chx2QQKP1nl/k80/Femm ZA6s5yw0Ga0n4DDE6Oqoff3SPRo0bLPcB9qci717UV12bi8zHt2/Z56zo1mIxbaJDF4/ uJOjdvFJXpxEaxJ+mgX5+CeiVCbs4sSQNwuY99MF0zUYeQXO1YZl6izdFsjL9mr/YRLg WWjw== X-Gm-Message-State: AGi0PubGVJbhbht0SijBC/TEk7TIkq9kHTF2CUuToT+IlDpMhzmEObok PYLCI+kV6FB1GqkqJpGFnJYI/mjV X-Google-Smtp-Source: APiQypIR53+c5PLkdX8ogSrGDs8oY2xPWNQzGfRyVgnggjNuE0V8f2c443g5rfz2AjKby/k5POqBhQ== X-Received: by 2002:a17:90a:fd0c:: with SMTP id cv12mr3765334pjb.95.1587237931226; Sat, 18 Apr 2020 12:25:31 -0700 (PDT) Received: from ?IPv6:2600:8802:5900:13c4::1017? ([2600:8802:5900:13c4::1017]) by smtp.gmail.com with ESMTPSA id 4sm7805226pfo.198.2020.04.18.12.25.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Apr 2020 12:25:30 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B44838AA-AB4D-4B9C-A25A-B69B0BF3AC46 Content-Transfer-Encoding: 7bit From: Fred Baker Mime-Version: 1.0 (1.0) Date: Sat, 18 Apr 2020 12:25:29 -0700 Message-Id: <81E617FB-6D55-4D8F-87C7-44DD23108BC8@gmail.com> To: IPv6 Operations X-Mailer: iPad Mail (17E262) Archived-At: Subject: [v6ops] IETF 108 planning X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Apr 2020 19:25:34 -0000 --Apple-Mail-B44838AA-AB4D-4B9C-A25A-B69B0BF3AC46 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ron and I are starting the planning for IETF 108. Alissa has told the workin= g group chairs that there is a distinct chance that it will be entirely virt= ual. Whatever the rest of the IETF does, I expect there will be some of us t= hat are not permitted to travel there - at least one speaker has told me tha= t. And I=E2=80=99m scratching my head on the agenda. Each meeting, I say about 30 days before the repository closes that =E2=80=9C= if someone has a draft they want to file, now would be the perfect time to d= o so.=E2=80=9D Consider that said. We are in the process of working group la= st calls on five drafts, which I expect to result in updated drafts placed i= n Warren=E2=80=99s in-basket. Those are each named =E2=80=9Cdraft-Ietf-v6ops= -*=E2=80=9D or =E2=80=9Cdraft-Ietf-dhc-*=E2=80=9D.=20 My understanding is that, with one possible exception, the working group doe= sn=E2=80=99t find our other posted individual submissions (draft-name-v6ops-= *) operationally interesting. So I=E2=80=99m looking for one, perhaps both, o= f two things: new drafts that the working group, when asked, says =E2=80=9Ct= his is important; we need to discuss this=E2=80=9D, or statements by other t= han an author/editor that the individual submissions are operationally inter= esting. In each case, as always, I=E2=80=99m looking for supportive list dis= cussion; that can include the authors/editors, of course, but most interesti= ng are folks that have no vested interest saying =E2=80=9CI would like to im= plement this in my network.=E2=80=9D So, I=E2=80=99m looking for drafts to discuss. We also, for the past several years, been giving operators an opportunity to= talk about IPv6 (and especially IPv6-only) deployment in their networks. If= you look in the proceedings starting with about IETF 98, we have had one pe= r meeting with the exception of IETF 107. What I am looking for there is - letting operators talk with each other - is there work that we, the IETF, need to be doing and haven=E2=80=99t d= one? Right now, I have three folks that have asked me for air time: Ben Kyemba, RENU (IPv6 deployment in RENU, NREN in Uganda) Jen Linkova, Google, (the process of turning off IPv4) Chifei Xie, China Telecom (Chinese IPv6 usage statistics, which differ= from Google, Akamai, and APNIC numbers) A topic I would like to see discussed (but I=E2=80=99m missing some importan= t details) would be an IPv6-capable network security survey tool. One issue e= nterprises raise with IPv6 is that appliances and tools they use for IPv4 se= curity are not available (or not well known) as applying the same tests to I= Pv6 and thereby testing a network=E2=80=99s IPv6 security In a comparable wa= y. If someone has one they would recommend, especially if they have experien= ce using it, I=E2=80=99d like to add a talk on that topic to the above four.= So, to put hands and feet on this, I=E2=80=99m thinking of scheduling a two h= our virtual interim and asking those three or four speakers to participate i= n it. If we have new draft(s) with working group support, I=E2=80=99ll inclu= de those as well, of course, but that would be in a separate meeting. So, I have a couple of questions, besides =E2=80=9Cplease post drafts=E2=80=9D= . 1) do you find the speakers listed above interesting? 2) would you rather meet f2f in Madrid during the scheduled IETF week? =E2=80=9C =E2=80=9C =E2=80=9C meet virtually during the scheduled IETF w= eek =E2=80=9C =E2=80=9C =E2=80=9C would you rather have one or two virtual i= nterims? 3) if you=E2=80=99re interested in a virtual interim, when would you like to= do it? Fill in the doodle poll: https://doodle.com/poll/4fw2d6d56fyi2tw4= --Apple-Mail-B44838AA-AB4D-4B9C-A25A-B69B0BF3AC46 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ron and I are starting the planning for IET= F 108. Alissa has told the working group chairs that there is a distinct cha= nce that it will be entirely virtual. Whatever the rest of the IETF does, I e= xpect there will be some of us that are not permitted to travel there - at l= east one speaker has told me that. And I=E2=80=99m scratching my head on the= agenda.

Each meeting, I say about 30 days before the rep= ository closes that =E2=80=9Cif someone has a draft they want to file, now w= ould be the perfect time to do so.=E2=80=9D Consider that said. We are in th= e process of working group last calls on five drafts, which I expect to resu= lt in updated drafts placed in Warren=E2=80=99s in-basket. Those are each na= med =E2=80=9Cdraft-Ietf-v6ops-*=E2=80=9D or =E2=80=9Cdraft-Ietf-dhc-*=E2=80=9D= . 

My understanding is that, with one possible= exception, the working group doesn=E2=80=99t find our other posted individu= al submissions (draft-name-v6ops-*) operationally interesting. So I=E2=80=99= m looking for one, perhaps both, of two things: new drafts that the working g= roup, when asked, says =E2=80=9Cthis is important; we need to discuss this=E2= =80=9D, or statements by other than an author/editor that the individual sub= missions are operationally interesting. In each case, as always, I=E2=80=99m= looking for supportive list discussion; that can include the authors/editor= s, of course, but most interesting are folks that have no vested interest sa= ying =E2=80=9CI would like to implement this in my network.=E2=80=9D

So, I=E2=80=99m looking for drafts to discuss.
<= br>
We also, for the past several years, been giving operators an o= pportunity to talk about IPv6 (and especially IPv6-only) deployment in their= networks. If you look in the proceedings starting with about IETF 98, we ha= ve had one per meeting with the exception of IETF 107. What I am looking for= there is

   - letting operators talk wit= h each other
   - is there work that we, the IETF, need t= o be doing and haven=E2=80=99t done?

Right now, I h= ave three folks that have asked me for air time:

&n= bsp;     Ben Kyemba, RENU (IPv6 deployment in RENU, NREN in Uganda= )
      Jen Linkova, Google, (the process of turnin= g off IPv4)
      Chifei Xie, China Telecom (Chines= e IPv6 usage statistics, which differ from Google, Akamai, and APNIC numbers= )

A topic I would like to see discussed (but I=E2=80= =99m missing some important details) would be an IPv6-capable network securi= ty survey tool. One issue enterprises raise with IPv6 is that appliances and= tools they use for IPv4 security are not available (or not well known) as a= pplying the same tests to IPv6 and thereby testing a network=E2=80=99s IPv6 s= ecurity In a comparable way. If someone has one they would recommend, especi= ally if they have experience using it, I=E2=80=99d like to add a talk on tha= t topic to the above four.

So, to put hands and fee= t on this, I=E2=80=99m thinking of scheduling a two hour virtual interim and= asking those three or four speakers to participate in it. If we have new dr= aft(s) with working group support, I=E2=80=99ll include those as well, of co= urse, but that would be in a separate meeting.

So, I= have a couple of questions, besides =E2=80=9Cplease post drafts=E2=80=9D.

1) do you find the speakers listed above interesting= ?
2) would you rather meet f2f in Madrid during the scheduled IETF= week?
     =E2=80=9C =E2=80=9C =E2=80=9C meet virt= ually during the scheduled IETF week
     =E2=80=9C= =E2=80=9C =E2=80=9C would you rather have one or two virtual interims?
3) if you=E2=80=99re interested in a virtual interim, when would you l= ike to do it? Fill in the doodle poll: https://doodle.com/poll/4fw2d6d56fyi2tw4
= --Apple-Mail-B44838AA-AB4D-4B9C-A25A-B69B0BF3AC46-- From nobody Sat Apr 18 14:56:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6923A1285 for ; Sat, 18 Apr 2020 14:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlc9Sc_rgf1w for ; Sat, 18 Apr 2020 14:56:47 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4A23A1288 for ; Sat, 18 Apr 2020 14:56:47 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id k18so2444926pll.6 for ; Sat, 18 Apr 2020 14:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=CJT+Gvm0ZPnsypbkSrdTp3FkRkRtA7Vh+L5OK1fKFZo=; b=SuNfDKYj/5zRYytyOS9CMstXz6mJ+cSRIKdZzTrFfOwrsxdOz3A0W4Ex6I6oAl2z9z JmAtkbVK4LVmDVnyDiniesACkGl6+JlX7VssVI/1bbXYDLCCrP6HRKL42Y5XSvzMDWxh HArjB0VKw/3jvDDgCktrvTWHb/NxBj61APvUOhLVZXTzmsGBLEO3pWnLy5IjI05U2x6Z yfe8IhmhCmypY/+5NA/zblyDjISzcVME0Z1aYxIaeQWbJ9BAFK0zow08FV2pheqA+d36 71cHxn/T5D1C1qi8AgDSpT3XA+L1ZwYo9t5OXEhLTrNf92LMpekj5RjSRhU6oHJg8ZJY vLsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CJT+Gvm0ZPnsypbkSrdTp3FkRkRtA7Vh+L5OK1fKFZo=; b=jyt1VW3S7zwnS1ulaaxhJjwhDWZFXA4yqcAVhIPIU8mlC0gXlYCyT/5wwN/8IG4qDq G+UYomEpOHNBfGVlnzkxenZPUZmdt1MsZ+Ub8qVfUzW5LQLrmdol2oCH4Ulm020NhfLo ddbsMkacWg13W7RdYmMAiDuXFmoolaT99q84lXRlR9iTtDslJv03aHmka15BGG4Nbtqv 8cRBAsj6NrxntQzAalaFRxZPp7job+wZo3D//KJEdKkgqjnKbcrL4BUzQS2xnO5hfq6f 5+6FAaVnFvwTLk8FGel8RMaD0Sb1+pJTRMqi/a+maL2/MWMQpb9zNx0l5gIg59HdQpPv TJDw== X-Gm-Message-State: AGi0PubWq8wA1Fcw955dgUBqxo5UuR07KNJqpXQ+OknSXxCeQnhyhj8S TPVJSuGtYi/ETYvjBzwaEFNUdvfS X-Google-Smtp-Source: APiQypJDqFmT8PgaXfUAhzJGAtMqSqZXH4BKikyIWtFxx5BdSDEColxSrTMwQZsnAvZqtpLBlFnK2g== X-Received: by 2002:a17:90a:12c3:: with SMTP id b3mr5273625pjg.57.1587247006144; Sat, 18 Apr 2020 14:56:46 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id i187sm22958010pfg.33.2020.04.18.14.56.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Apr 2020 14:56:45 -0700 (PDT) To: Fred Baker , IPv6 Operations References: <81E617FB-6D55-4D8F-87C7-44DD23108BC8@gmail.com> From: Brian E Carpenter Message-ID: <689abd4d-545e-d12a-9745-ab64719fe630@gmail.com> Date: Sun, 19 Apr 2020 09:56:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <81E617FB-6D55-4D8F-87C7-44DD23108BC8@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IETF 108 planning X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Apr 2020 21:56:48 -0000 On 19-Apr-20 07:25, Fred Baker wrote: =2E.. > Right now, I have three folks that have asked me for air time: >=20 > =C2=A0 =C2=A0 =C2=A0 Ben Kyemba, RENU (IPv6 deployment in RENU, NREN in= Uganda) > =C2=A0 =C2=A0 =C2=A0 Jen Linkova, Google, (the process of turning off I= Pv4) > =C2=A0 =C2=A0 =C2=A0 Chifei Xie, China Telecom (Chinese IPv6 usage stat= istics, which differ from Google, Akamai, and APNIC numbers) Great topics, but I would be 100% happy to read three drafts about them. = I'd be willing to flip through slide decks. I'd be unlikely to listen to = narrated slide decks or watch videos. As for live air time, I would consider tuning in for Q/A on these topics.= I see no reason to waste air time on slides, since we can all read stuff= in advance. I think that using virtual meeting time for topics where the= re is no draft should be avoided. > 1) do you find the speakers listed above interesting? As stated: good topics for drafts + Q/A > 2) would you rather meet f2f in Madrid during the scheduled IETF week? Zero chance. At least where I live, international travel will be impossib= le then. > =C2=A0 =C2=A0 =C2=A0=E2=80=9C =E2=80=9C =E2=80=9C meet virtually during= the scheduled IETF week No particular advantage to that week. > =C2=A0 =C2=A0 =C2=A0=E2=80=9C =E2=80=9C =E2=80=9C would you rather have= one or two virtual interims? I think you might want to plan on one every couple of months for the inde= finite future. That's twice as many deadlines per year, so the pace of wo= rk might pick up :-). > 3) if you=E2=80=99re interested in a virtual interim, when would you li= ke to do it? Fill in the doodle poll:=C2=A0https://doodle.com/poll/4fw2d6= d56fyi2tw4 Done, but you're unlikely to cater for my time zone (UTC+12). Stay well, Brian From nobody Sat Apr 18 16:08:58 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871713A13CE for ; Sat, 18 Apr 2020 16:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8jZlLceF7y3 for ; Sat, 18 Apr 2020 16:08:55 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566613A13CC for ; Sat, 18 Apr 2020 16:08:50 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id g2so2496120plo.3 for ; Sat, 18 Apr 2020 16:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mADy7idMGvIeBg6VQw9veMPMgWIqQCUZlw0m3zgfcZY=; b=gXARKo0hbs5nfJjh4Dbwjybzo7SbFI4uhywzCt244GJAS8StzfHYVpaol7e7kCMPB0 wtOtaer3S4s1tvz83D+qOqeMPQbo6oQeBGOWVNEYjiIlTQB0iqqUotZsNHhf8W3MVurQ ykm4BAn8Asl7IbrPV2fGd1eYgg/Z+ocnw3+ZUetmlo96AwCvIYbsD35umdCixi5mMoIg d5tK7UN/iS6vhDQAb/SPL34ZZQbmb1WI7pr52zRC/+m8/KXZcTitfdKfpW0TUuEtXoFC 6Fho5MMOzclHd68/p3aEXWsIn1Bd1xB+0p7NtjJN6wA2uhlFjxy1j8HiomjWq0IvqHjZ Pf+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=mADy7idMGvIeBg6VQw9veMPMgWIqQCUZlw0m3zgfcZY=; b=K41nI8Ra7QRxBy8ed7Cghl0bB9pzlybCdj7mlPbMRsysjOk7IIXa7d8kXJOXb4JN2W R3MLViO+TzWZjs0M8EBBo5ZZQnFXgWceitaBX62bvUIk9c0jgKJ+C32dDuvqhgGryH4N H6m66X9pT43/V4Kc5Gm4XLKkl2qIY3ZvGE5vJJe9eFuhzjhXTV9FYuCigTyQVYWuwfyS ohrp0VFmv3Isa60/kbOEoAlfuXWdfaiNZ2r1ibrQe7uKFgAvSKqpDaRXqC5BxrFbzMzI /LDLttRSBgaXoIAL3bSPiZlGkRhqWiYfMPxeeYzjRnwIYwhn+4sA9VWih0iTGjb/gJJo jssA== X-Gm-Message-State: AGi0PuYjDij2c+KdBn/g5RI8CrNxMKvNnmcZFqW7onitRXr+ktVS++XJ eye1B5aI1Q7ir4O3jBUnkDHql4vk X-Google-Smtp-Source: APiQypKV7cqUSdQXDuGBY15y/kYNvMjP9YjVsfSA9Kw1nmtLBfJs/Oqvx4Q2ouubNhm99zomOpEJKA== X-Received: by 2002:a17:90a:bf86:: with SMTP id d6mr11973734pjs.180.1587251329462; Sat, 18 Apr 2020 16:08:49 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id p62sm15734331pfb.93.2020.04.18.16.08.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Apr 2020 16:08:48 -0700 (PDT) From: Brian E Carpenter To: Ron Bonica , "v6ops@ietf.org" References: <202004131539.03DFd08A043411@svl-junos-d082.juniper.net> Organization: University of Auckland Message-ID: <94caf906-c65e-acc8-814e-ad7ced9b7547@gmail.com> Date: Sun, 19 Apr 2020 11:08:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Working Group Last Call draft-ietf-v6ops-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Apr 2020 23:08:57 -0000 In my opinion this is ready. Just some nits: > This is clear indication ==> This is a clear indication > Rather than try to preclude how operators may run their networks, ==> Rather than trying to regulate how operators may run their networks, > o Item "e)" of Section 5.5.3 of [RFC4862] specifies that an RA may > never reduce the "RemainingLifetime" more than to two hours. ==> ... never reduce the "RemainingLifetime" to less than two hours. > The following subsections discuss possible operational workarounds > for the aforementioned problem. ===> ... aforementioned problems. > may want or may need to employ dynamic prefixes ===> may want or may need to employ dynamic prefixes. > [I-D.gont-v6ops-cpe-slaac-renum] ===> [I-D.ietf-v6ops-cpe-slaac-renum] Regards Brian Carpenter On 14-Apr-20 03:43, Ron Bonica wrote: > Folks, > > This message initiates a WG Last Call on draft-ietf-v6ops-slaac-renum. > > Please submit comments by April 27, 2020. > > Fred and Ron > > > Juniper Business Use Only > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Apr 27 10:05:08 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA0E3A114C for ; Mon, 27 Apr 2020 10:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=oAWqgTj9; dkim=pass (1024-bit key) header.d=juniper.net header.b=Kb1WXuoB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAgyY0gDsl2I for ; Mon, 27 Apr 2020 10:05:01 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 C9D2A3A1148 for ; Mon, 27 Apr 2020 10:05:01 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03RGuXHS002045 for ; Mon, 27 Apr 2020 10:05:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=MFgWJko5Ony/ayLrT1zvaJnvVo4XDysmVc60SINxFKQ=; b=oAWqgTj9b18KGTaehV7vi7nkfEePPjRNAUcHJyAvdWyUkdvwHENMsAhSFcHzID4c/TSv UhUmp7jX1tGEV6j1Eoh6ob4ofOgFsmVCO1P3UHzGLOLNHx5whHEzYv+DKFMVQCt5xWC7 +ohByO2ynLqu/aDhPNXHr/B7VTNMI8fz/4Niu8bLIxXdk2pEbCk9Q3hZVOTM7I+c+gng AMYgRa3aaisHFLGam/ggsTnPudBYWPMFe2r3Zbez8S+e9Wtf1maBuL8021TJnVdU0NiX PzFLez49qbnsNvz+G42LobqR2kHeUryJoBKIjtOPfpNKzy1fE52VJtwIz9VoWwKgohyk rA== Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2045.outbound.protection.outlook.com [104.47.66.45]) by mx0b-00273201.pphosted.com with ESMTP id 30mkf8u9pc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 27 Apr 2020 10:05:00 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aDTcKRBVZpzNpC5sDZCovgfVqgxRciwLPSOnXuESSFtFaYgXHv8G+lQlM8U3MuchTvIdFJ87ZE9hyDteELSu5RmHAZX4WlyLEq837hiyUt5an2WHH2waYHWEVG6zhPTKk4tpVmnz98UVJS0P11V9JGjpL0us/BMCwJaeS7I3uUVLpSI6JpOkA0fetkjd6vX0TWh22BGafvQrlY8z9hS6+78BZPQ9Nb+wIPwBrt8xZyUPCg97zx6c+jTUzjjblSH08Xu+hLGxzPbNoUum00wessrVemKTjQcD6vTPGKBN3dDVLHni05r4i0IWL52jZilGeCtAs3+GEQDYQW7Idl+KsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MFgWJko5Ony/ayLrT1zvaJnvVo4XDysmVc60SINxFKQ=; b=RrdTjn2/+sWI6OpJGenMEqMYuxvh3i1CStSVt+1BjoKIw6DV/Mbp5hjE+zH+l2HSQeUFyjoYBW5megcEWFtFPqBgFgU2mKtVaIfNGiQUaut/DswOKWE7H0VgUO3IqjBxcucO1djUJkx8OKTQFjfOctsdHlCrvHZbepw+GpM8cTpKVDip9+1gxGsjVIia7pI9GRAxYd4oyFzllRJJqsGtcmp1o5Wd28mgybaQPZfWrBMMA4abD9zulRA6ka6cViWtsi+czbf72wKQbYQlvCw8n1Z0jBjwvQEnb3r1kBbJYTooaHtxpufZvw20nNdqUTvQICAGKMOooBrpcsu+vs4Dpw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MFgWJko5Ony/ayLrT1zvaJnvVo4XDysmVc60SINxFKQ=; b=Kb1WXuoBZtrEeXJrSSKkPSj8h1Uoze/UIUKg3kr9oEkBLqzv4yc6ak+wUI8+Qa/dOwqUs1BmEuhI8u/FNSxFEIxPu589C3lCiDEwwcUVQ50v9KFH8HXfNgz7Gg6VO78z04gJVzSChq+awkkR2+C5BwS3p0eSYaYgRGT5arQOVPs= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB4764.namprd05.prod.outlook.com (2603:10b6:5:10::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.11; Mon, 27 Apr 2020 17:04:58 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3%4]) with mapi id 15.20.2958.014; Mon, 27 Apr 2020 17:04:58 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: Working Group Last Call draft-ietf-v6ops-464xlat-optimization Thread-Index: AdYctd4SN4W+g4f1Qv+PH7zqOij0sg== Date: Mon, 27 Apr 2020 17:04:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-04-27T17:04:55.4830453Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=6d06b143-0f3c-4b8f-96ae-3e14a590d61d; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7c28f75b-8a3d-40ef-5aa9-08d7eacd1dea x-ms-traffictypediagnostic: DM6PR05MB4764: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2089; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(376002)(39860400002)(366004)(136003)(66556008)(5660300002)(55016002)(52536014)(64756008)(66946007)(558084003)(66476007)(66446008)(76116006)(186003)(7696005)(2906002)(71200400001)(6916009)(6506007)(86362001)(33656002)(478600001)(316002)(26005)(8676002)(81156014)(9686003)(8936002); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hHoxiLW6kxwnnu5W0vqRSVCYq17wuaaRqymuPN4x1ZdiCVWav4jWz0ap8rS+Wl7sdkqJLGPp72NVSjLD22+FP9K5K3q6uz7grEKi18uA/F/81Xy7MW73+cXdVaFK6X9zUUxs4bZ7UjxOduw3kvddAHriPyD4jYaIXyk4YvfTuZP4MjfAE/mgPIIlb9HhLfSEnZCneX+zZrwLUn4VVRiQXXNZTGzKVqxad0pdjZ+aV3q5/kS5oxM6eT9+Xfxl2jBM64E8kyJq8BQdZE4cDHrjqIAAOB7XdXR+6DgY+r5ipG1bnkR4Xm0OaAepAVL19KYj5EhUB6XRBptLtF4PThuKeniIPVOZjx3HtSyGp1QDIHGxjOT3W/0icLrwWlCMHhYuUTN+9hXTFTxNnsKqDE+Cn1/OwDbKOP0qnheljhm0qTr6CGw9rFs93VGGyRGcuhhz x-ms-exchange-antispam-messagedata: Abscc3AMj4Xb8GHguM2qzggnt+1CFss0JhEnGVTzNAEqJh5x8FlEpuEPuQM+qeZE1NZ5tAhq+qLlb6LLH2B2xAl7H5Fqqk/u09gGwPMm9r5PaluCT7xrghCVgVEBRt2+lDx3XhAAyc4WT9GMxwXQ81YMiIBYRBe/u17VkRGyzFf/zuj3c2mj/pv8udPUkV5QWyyaSkBmkytWOfukwMuKtdqOBRVdjIuYTiDFUa5fLopzJOHqSi8Qoaw14NEL5ks3P9VEo8Yg8QBZL92UHcY3BwPC1VWfLS2iDFe89mQ7iTqaPfSXnNq8nDD4dqWLHvxZd73wpJfkOk1+F8JmAziPKI6BTCJewLLGT6kPXyZDvV+akFCOSRtXQkdu4ro13UOg+VxdlsOFSWaI0DFTZz7OJH5U5wdiwRcEz1WvW/rifpULKTMHZioy7UtS7UOYbLk2c2PtLfVPDfQyX+PopBO6ny2J3c9do4nm4pFd98IUobUnTcceUUIi9gCGIx0Z9fJVXkg3DrY9PH1/q8cfLE8MPKZJsSeKHZd0lJf5fDGrWNNoSlQgAfUmsGPXtBbHxV4fNnRT/Ve6crpPb7fCnYBELJKhJkWClQ5Q6UNP6B6j4XnP3ey045uxjyBx3U4CJXnN6/TLy1MyI78uB9zQ8wNmMS4vRLsGZ7SfW5+x1OyKQ8/G+CMbZn1zl/5acCUt0Z9M30E2bbRoGMzfqeJM+jntUZNh2HFcYs1yLHOOvFeDM0aeGQprcg//JmC3n8Riqk/42mZYNKeImLy6yJs8Wg//2FR4gY/i8igEYTe2vPGcU70= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 7c28f75b-8a3d-40ef-5aa9-08d7eacd1dea X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 17:04:58.6258 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kUGAzMefE6pkkjhgZs0MAUtPozxPikQbag3aQtK9irdqT4u1n3Pb0s/i2YjdRkqa11cZ7kcycmJo+7L39obqgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4764 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-27_12:2020-04-27, 2020-04-27 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 phishscore=0 mlxlogscore=590 impostorscore=0 bulkscore=0 suspectscore=0 malwarescore=0 priorityscore=1501 mlxscore=0 adultscore=0 spamscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004270138 Archived-At: Subject: [v6ops] Working Group Last Call draft-ietf-v6ops-464xlat-optimization X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Apr 2020 17:05:05 -0000 Folks, =20 This message initiates a WG Last Call on draft-ietf-v6ops-464xlat-optimizat= ion. =20 Please submit comments by May 11, 2020. =20 Fred and Ron Juniper Business Use Only