Re: [OPSEC] Opsdir early review of draft-ietf-opsec-v6-13

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Mon, 08 February 2021 15:50 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843863A0F4D; Mon, 8 Feb 2021 07:50:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 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_H2=-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=EIUoPgjf; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Y7N6fPVM
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAkyBNK_qA2G; Mon, 8 Feb 2021 07:50:52 -0800 (PST)
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 288923A1009; Mon, 8 Feb 2021 07:50:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12292; q=dns/txt; s=iport; t=1612799452; x=1614009052; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=2Y1ZENbIpygoOt+BvejsnsFCAUCkfALzXEcveKOJLVE=; b=EIUoPgjfEPlhhMagUjNGPiOUuAJ405js7SeIvYaiU5bDcSAGNqxLZipW GwMA2DnEk+2t61nWwCrd7VWqwYsMx59OUBPcfoFxb5lqqQE0CNLcr3WoA hFjbSsUA2rbTbZn1mgnKs4lbsrcROMkMyhTfI7N5ab65ms9BGICqh6z/t g=;
X-IPAS-Result: =?us-ascii?q?A0AQGACkXCFgkI0NJK1YCg4OAQI9AQQEAQQBBwEWgVEBg?= =?us-ascii?q?TsCAQEBAQEOUYFXNjGEQYNIA44QA48WigaCUwNUCwEBAQ0BAS0CBAEBhEsCF?= =?us-ascii?q?4FrAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAYY4DUMBEAGFHAEBA?= =?us-ascii?q?QQjBA0MAQEpDgELBAIBCBEDAQIDAiYCAgIwFQIBBQgCBAENBYMmglYDLgGkC?= =?us-ascii?q?QKKJXZ/M4MFAQEGhQUYghIJgQ4oAgEBAQEBAQGCcIJxUEeGRCYbgUE/gREnH?= =?us-ascii?q?IFYfj6DdRwFCoM3NIIsgVkBcQE8JgEDQzACLgYHDRsMBzcHDSAPAQESBQYJO?= =?us-ascii?q?pNGlAWQO4ELCoJ6kDeLTAMfoyKRZ4FWdZ0eBDGEIwICAgIEBQIOAQEGgSVII?= =?us-ascii?q?YFZcBUaSwGCPlAXAg2GZodVg1eKGEF0NwIGAQkBAQMJfIVkgnCCSAEB?=
IronPort-PHdr: =?us-ascii?q?9a23=3Awr6DdROWj4bJMvJei60l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwz3l3IRo6d4vkClumF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGGsflbBvbqTuv7m1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,162,1610409600"; d="scan'208";a="642905419"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Feb 2021 15:50:43 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 118FogKq002466 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Feb 2021 15:50:42 GMT
Received: from xfe-aln-005.cisco.com (173.37.135.125) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Feb 2021 09:50:42 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 8 Feb 2021 09:50:42 -0600
Received: from NAM12-BN8-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, 8 Feb 2021 09:50:42 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ER+RVC23gDag7mZ0gNuOAJaxQYJ6gRCDAAwnCfg4LKYc7wiR3vizdJoJv98GdfSpFx3E/S14fi6SdA+GaHKDXiPcf+qciMhjEX/e3GV8Bxt+EzUH3yJlZjDQQ2nLMVmoQtL5awcToL8e5sdojPeDmUtOdGt3QBhYWK5HiHpO9nlRIj250Qe4sQb+OHFzzTcJgt9pMc6cPicmOFShLVohPpYP94uNMGsmZAZ5wEbGQam8nexU0w0AXC9bxOTghfmVxzscv34igPmv54LZ+lA4mNOcXuhSENI9sQsWmbEZZbOrs4RIdYe7Rb4GOGo8v6TnfOsLfmWQucWNplGk+k1trA==
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=2Y1ZENbIpygoOt+BvejsnsFCAUCkfALzXEcveKOJLVE=; b=aBF0IOXiAYdzCq1A/vlfLWfUBGQUsKz7rcEl2QUvqtrdfhyqafrl1yCZiPqcZGcmrfbRL3pEbJn4q2YpWDLhWsh2vSnFlBIO+NiEmH4yNw8rlOeiKhjsrIYo7yHMYphcQzappOQ08KTbVCF+X/IevNesZ2f/8cazettTUtgwaKc0oAJSBGRLwNJupDoXiFpxdSo5JIP+XPwHWLCrbLGgfi+bEMALEXy59oZMHOnvST4cbJ2k/pPcBixxGLu77XduKUtHPHD8dm2z1F4U5Y0sGU/dXXLOSw7rszWNiIKfPOwUC4fRRMWVpY/fZgMx3WU5dvWAN4k2kpd7/u0Hqksz8w==
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=2Y1ZENbIpygoOt+BvejsnsFCAUCkfALzXEcveKOJLVE=; b=Y7N6fPVMYoXuQZmYsGFSnN+0yKX1ffl9kBY+7Icslw/5HERKc/gZ+gF56pCNO1aXGa4fvjAUI8msn9X0j+qdBSD8tCfcFIYv7QHBT0E1XXvwce60PjY3uaNsu4rZBj0/7tRZl9RKNIG8LWBu+hr4/39euIX3mVX/Yc0UswEjPDs=
Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4822.namprd11.prod.outlook.com (2603:10b6:510:39::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.27; Mon, 8 Feb 2021 15:50:41 +0000
Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b%3]) with mapi id 15.20.3825.030; Mon, 8 Feb 2021 15:50:41 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Tim Chown <tim.chown@jisc.ac.uk>, "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: "opsec@ietf.org" <opsec@ietf.org>, "draft-ietf-opsec-v6.all@ietf.org" <draft-ietf-opsec-v6.all@ietf.org>
Thread-Topic: [OPSEC] Opsdir early review of draft-ietf-opsec-v6-13
Thread-Index: AQHW/iu+EvH9Gs03J0OhFLCiKWpgsA==
Date: Mon, 8 Feb 2021 15:50:41 +0000
Message-ID: <AEBE3D2F-55AD-40EC-BC80-A9560C4E0298@cisco.com>
References: <153055392479.16095.569198674604354407@ietfa.amsl.com>
Accept-Language: fr-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.45.21011103
authentication-results: jisc.ac.uk; dkim=none (message not signed) header.d=none;jisc.ac.uk; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2001:420:c0c1:36:a139:7459:c380:8975]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f0735746-f934-4ff9-f973-08d8cc49499a
x-ms-traffictypediagnostic: PH0PR11MB4822:
x-microsoft-antispam-prvs: <PH0PR11MB4822B1FB4EA6E239A3ADD4D3A98F9@PH0PR11MB4822.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: aphIoIKXRUlUIJuSWf8jwLpcX/c2OUEuQK3ayU8oXWulGUAWSynK6f0kVdqloKGhjqM5H2jBhb+32wJTOJnF6O5rYT2KqSfbjED2tjsulBC8ljyd5suMgP/YHgLObkhSt5+T6W3hpWKmTqoGWc1FXVB7Yhw0Vl5WoTark/SsdyVxim2/Jy8bxjZPHiKGeIUmhXsA75vv9tnTc21mZrxN1wQRiivbsXwaurp8gqH3JfcTEsX3bw8Pw6lv0YNbd3Kxs7lWSfTg5h9hsD8GqVysOykIZZTbTSAd9+b1zo14WvPtmE7bjE/sAA6yh+n0vXV4BTaOZEHXZqp7KH+vKpNj0Vyu126zmm1f6Oj/EUytFMMeddG2e7mc0chlXPfTyvVofKECpRP52+4XEo3Ge5Y12hV3xnsTYB/71Zvc7keL2h0n0tRKC6A6wajgkHjF39qKkbCGaj/d9bUoDuFfbg3XUHMCz9mKNNUmkbSzc/DHF7G95I8jXP9/HVt954yzTbx7trFfg/XulwSpG9oDHr3oKkK621EyWuWldsT2yO2gSp+GHD1q/NaHJt+mfFgnMj9aPlkZ9RNO7qz+QQdmWAoLUw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(396003)(366004)(39860400002)(376002)(136003)(478600001)(33656002)(2616005)(4326008)(36756003)(6506007)(2906002)(66574015)(6512007)(71200400001)(53546011)(83380400001)(86362001)(8676002)(66946007)(186003)(316002)(64756008)(66446008)(66476007)(66556008)(8936002)(110136005)(54906003)(5660300002)(91956017)(6486002)(76116006)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?ZlRuU2tzM2MzWENtbFRENzhhajVobDg3SDlzdEZDaFZwWjJTcVFTOVRUSnB5?= =?utf-8?B?VEdhUmNsdzY5Zkpkdm1pcEFNWXNhZEdWZ3dpQ1VXV0xHNFRjdXcyL2E1WHZy?= =?utf-8?B?TEtiY2V4bHJyYm1qOE8vNHVsNjlEZWowdndPRkMwWUVkTXIwc3lFTC9rRG5J?= =?utf-8?B?Y1pEUTRUR2JRVlZwcnBzN2VqblViZE9oR3J1ZTUwYjJWUVRkUmdWWWQwQ05a?= =?utf-8?B?dXhwVCtVZ0x0Y0owbDdQUFo4ZmhCWGg0SmRHOW80TzI0TUVsa2x4TWowVmUv?= =?utf-8?B?WVZnT3FyVy9sMEo4OVRiUG04OE5Ua2xqeENrdkVITVIzNGttREtZYVNXdGZ5?= =?utf-8?B?MUhFY3l0bVpBM2NGZXVBNEphaDhEUnJzU0Z0YXhVeWx3aGEyRHBCNVdMZENG?= =?utf-8?B?ZnBIb0tDMitpc1pWWThWemJ5S2krWk4rTmt5MnpRTmtoSFdCUzdvQkkzS1lZ?= =?utf-8?B?N0w5cTN0UFBRdTlsS0ZDUnJrekV6RUtWVDRKbmN5WmthejhiWDRyNDlrcFln?= =?utf-8?B?MTZBSHZ3V2haUnd3OUVOclR5U3JMTmR5ZWduRjU3R2t3TWdaaVdpa1dNZ1Jz?= =?utf-8?B?Z2JFTVg0SUdPbkdTMFRLQ1pEUEJvU2dMTTd5Qkh3UmRHSUVKQ0lLN1ZvekJn?= =?utf-8?B?YTFKNjRybGpnNlVNMDd2RXdDTmNyRzdzNU1mYmgxWFVTTi9QUjlhNnBVUTB3?= =?utf-8?B?VWZHcUtQYTk3eWZCZWtwMGNaOXI3b3Q1V3J2RmdEc1BPS1RqNnYrT0F1L3Jy?= =?utf-8?B?ZVVUc3JUbHpmVHNXeXFZUDlDSXRqV1BHWFNXZjJPNkpYVG9TSFQ5N1BsNEJO?= =?utf-8?B?S1JZUTMvbm0wa2tTNDYrbFdGeU5pVHVOVWNvL1M0Tm5JeWV2cVhuRm4vbnla?= =?utf-8?B?eEVMSzk4Q01penFpZm93Vmh3N3pGU3RNUGZIdUhZQUFiakNMQmVyOEk1b3lK?= =?utf-8?B?Z2xpTVRpUkNqR1VLSUJocmNBRUovcEVyZXJEakdFMFVvcytOQy9EVU9QR2kx?= =?utf-8?B?WFVYelZMemIxSDlES1I4ZTdmenRpTXFsSnE3VHZJWWJJYkRpRml6WUVaSmQ3?= =?utf-8?B?blE1QXh5N2pMYWUyOW1ZZ2VtekpJWlI1ZlJlYXhhZFVmWnMwNGVLSVduaGsx?= =?utf-8?B?N25IMjlMbHVBc2JHUVFLMUp2ZCtWVktLMHVCTVkrbUVickdFMDR3VHdQK3VS?= =?utf-8?B?WWRuQ1o2ZHB4d05VMDNDMnlUSXlLNjhEa3IrY2N5MkRHK3V4bWVySjUxSGlI?= =?utf-8?B?aWlhL1VLRFdmSWhwMXNzWUVyYXlTNEIzTUhCUHRLOWVvVlhJOFdGMlV1RWFB?= =?utf-8?B?cnZJbW9WQTFtLzNtczB6V2h0TnVQZXplMWdON2plbXlWaU9TSU16K21JNVQ3?= =?utf-8?B?eHBxWUNza2tRUURXc3FORys1N0tad2xPSGJYYkcxZkw4Y1c4TGt0MDltRHdH?= =?utf-8?B?ZEVwVExab1haTHpCVnk5bmQ5ampaS2pyeHg0M2h1UDN2aUxMVVBmc1FLOGky?= =?utf-8?B?ZXQvQ29mVkk0VjkvVElCZkxmdG94Wk56bmRnTVY1ckpPM2E3aDJRZ0FhazZn?= =?utf-8?B?OTJUYmlnZGlqUUdvRi9BVTNrMkJ0QVR0eDF4TGwzL2tFTmJqMVp6VGhHdzgv?= =?utf-8?B?c1BTMlNsaWNyTHllUGNqamQ2RHRLcllRMGpiMkRVWmJWbXpkNXo2blJwN1NG?= =?utf-8?B?c1NwUTM3aFIyQ0o4b2JFciszNFovUVJIUThOV3p0STZ3RUltbGhOUjNYdWc0?= =?utf-8?B?VDFKUmZpcXFZTTlVTy9aMUN6TGtiTzI0N0lkT2RLYng4ODBrK0pmSTFsdWgx?= =?utf-8?B?N09IQ0Nab0tzdHJHSTBTMDN3R3M0RlZPQmVqN2U0Y0xid3k0cXJhVUVVYW56?= =?utf-8?Q?5tWX3nKY71kvO?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <0774227188E8B54EBEDC6EF0C1C1CE36@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f0735746-f934-4ff9-f973-08d8cc49499a
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2021 15:50:41.1949 (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: l0jLuzF8+P/43aoQsfRhnoJR1246C01wYDchPe1g7BmECiA9beB8WVpyj1RZvoB8bBJ8HXkh8ky8l5zjPc2sZw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4822
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/rrcUP3WnFdDJby2pOqb-uigcDqM>
Subject: Re: [OPSEC] Opsdir early review of draft-ietf-opsec-v6-13
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2021 15:50:55 -0000

Hello Tim,

Better very late than never… Having some time this week to make some progress on this I-D... I hope to publish a -22 before the IETF-110.

Some comments on the outdated review are prefixed with EV>

Thank you for your review :-)

-éric

-----Original Message-----
From: Tim Chown <tim.chown@jisc.ac.uk>
Date: Monday, 2 July 2018 at 19:52
To: <ops-dir@ietf.org>
Cc: <opsec@ietf.org>rg>, <draft-ietf-opsec-v6.all@ietf.org>
Subject: [OPSEC] Opsdir early review of draft-ietf-opsec-v6-13

    Hi,

    I have reviewed this document as part of the Operational directorate's ongoing
    effort to review all IETF documents being processed by the IESG.  These
    comments were written with the intent of improving the operational aspects of
    the IETF drafts. Comments that are not addressed in last call may be included
    in AD reviews during the IESG review.  Document editors and WG chairs should
    treat these comments just like any other last call comments.

    This draft analyses operational security issues related to the deployment of
    IPv6, and describes appropriate mechanisms and practices to mitigate potential
    threats.

    The document is Not Ready for publication.

    General comments:

    The draft is well written, and the authors are clearly experts in the area, but
    the evolution of 13 versions of the draft since WG adoption in 2012 means the
    draft is somewhat disjoint, and has a number of sections where current best
    practices and related RFCs are not included.  A prime example is in the area of
    address configuration.

    There are seven pages on transition technologies; might that be better homed in
    a -bis of RFC 4942?

EV> we tried to be exhaustive and gather all (?) references in this single document even at the expense of 7 pages.

    The sections on control plane and routing (2.4, 2.5) are somewhat generic to
    IPv4 and IPv6; there is very little IPv6-specific information in there. While
    this isn't bad per se, it pads the length of the document somewhat without much
    new material.

EV> agreed, I have added a preamble with your warning and pointing to the difference between IPv4 and IPv6 but keeping the section as it contains many valuable reference (IMHO).

    There are many typos and grammatical errors throughout the document.

EV> with not a single author being native English speaker no wonder... The document will go through a spell checker.

    Specific comments:

    p.3

    "subtle differences between IPv4 and IPv6" - I don't think L2 vs L3 resolution,
    ND vs ARP, is that subtle?

EV> changed into "subtle but critical and important differences "

    Do we need to mention NPTv6 here?

EV> added

    p.4

    Mention 6renum and the gaps draft it produced (RFC 7010)?

EV> added

    The recommendation to use PI for a larger network implicitly means no NPTv6?

EV> the text has been modified in more recent versions.

    Any value in adding a note about the size of prefix an ISP offers?  (6177, etc)
     That affects how the network is configured.

EV> indeed, good catch !

    Where is topology discovery / probing mentioned?  Cite RFC 4864?

EV> the 'scanning' reference is probably enough as it is and this section has heavily been reworded.

    p.5

    I think the phrase in para 1 is "security by obscurity".  I would argue that
    that can complement other security, but must not be depended upon!

EV> added (even if it is mostly obvious)

    Para 2 - or do both!

    p.6

    Section 2.1.3 - and ND cache exhaustion protection

EV> not changing the section title to be consistent with the other section titles. The newer text is also clear on the ND cache issue.

    Section 2.1.4 - "Normal" SLAAC no longer relies on EUI-64 from MAC addresses -
    now RFC 8064 recommends the RFC 7217 version of SLAAC.

EV> the whole section is indeed completely rewritten now

    This whole section is written in a jumbled order.

    There should be a separate section on address accountability - whether it's
    needed in a given scenario, and where it is, how best to achieve it - there's
    bits of this scattered around in many places, but it's independent of privacy
    addressing.

    Para 3 - see section 2.1.7.

    p.7

    first line - you can't always control managed vs unmanaged of course; a
    university eduroam WiFi is unmanaged, generally, where admin systems probably
    are managed.

EV> this while section has been rewritten, so, some comments do not apply anymore

    second para - these are just hints; and for a host not supporting DHCPv6, it
    gets no address at all.  Perhaps also mention SAVI here.

    Section 2.1.6 - Should mentioned DHCPv6 anonymity profile - RFC 7824 and RFC
    7844.  RFC 7934 suggests not using DHCPv6 in certain circumstances as a result.
     Also RFC 7077 recommends to not issue DHCPv6 addresses sequentially from a
    small pool.

EV> modified (thank you for the references)

    Section 2.1.7 - note RFC 8273 is designed for shared environments, and
    isolation is a primary goal; add reference to RFC 7934.

EV> the latest intro to section 2.1 has such a text

    p.8

    Perhaps check against text in draft-ietf-6man-rfc6434-bis-08 in section 5.2,
    and the excessive EH option processing text in 5.3 there.

EV> added reference to RFC 8504

    p.9

    Section 2.2.4 - worth adding RFC 8221 and RFC 8247?

EV> I do not think so as those are really generic and not linked to IPv6 (and I know that control plane/routing are mostly identical but they are at least some differences)

    Section 2.3 - split out the NS/NA messaging here from ND in general, else you
    should include SLAAC.  Given you discuss SLAAC later, focus on NS/NA here in
    its own subsection?

EV> flow has changed based on your comment

    p.10

    Spurious DHCP-Shield wording at end of para 2.

EV> fixed

    Section 2.3.2 - mention ND cache exhaustion

EV> done

    p.11

    Rate limit also on ICMP messages?

    Perhaps separate out the power drain issue as a threat?  RFC 7772 is relevant
    here.

    The two drafts cited here by thubert and chakrabarti died in 2012 and 2015
    respectively?   Maybe RFC 6775 instead?

EV> indeed! Done

    Section 2.3.3 - or just supply a 'bad' DNS resolver address

EV> added

    p.12

    After para 3 emphasise still need RAs in a DHC environment for default router
    and on-link prefix(es)

EV> indeed, added
    p.13

    A lot of text on something hardly used?

EV> let's leave the SeND text here anyway for archival __

    p.14 - 20
    Lots of generic text applicable to IPv4 too?

EV> true of course, added preamble to state the congruence but also pointing to the differences

    p.16

    Replace RFC 2460 with RFC 8200?

EV> left the reference but added text about 8200

    p.17

    There is now draft-ietf-6man-rfc6434-bis-08

EV> even RFC 8504 now __ but the text has been heavily modified anyway

    p.20

    What's required to differentiate logging of different IP versions?

EV> added text rfcaround ipVersion from IANA

    Value in mentioning RFC 8096?

EV> I do not think so

    Or YANG modules (as per Section 16 of draft-ietf-6man-rfc6434-bis-08)

EV> more recent versions have already this text __

    p.21

    And RESTCONF?

EV> see above

    Windows 7?

EV> just a data point... at the time of writing

    At bottom, "was usually done in the IPv4 era" -> "is commonly used in IPv4
    networking"

EV> possibly better wording

    p.22

    "era" again.

EV> done
    Mention DHCPv6 anonymity profiles - RFC 7844

EV> mentioned earlier

    P.23

    Forensics - that's *one* way - can e.g. use a NMS; one that harvests network
    device data via SNMP; many open source options available.

EV> text has changed in more recent versions

    p.24

    Mostly duplicating RFC 7077.

EV> or making a short summary of RFC 7077 ;-)

    Section 2.6.2.3 - rfer to RFC 5952, or se Sec 2.6.1.1

EV> text has changed in more recent versions

    p.26

    Perhaps be consistent with rather than maintain parity?

EV> better wording indeed

    p.29

    6to4...?

EV> I know... current versions clearly identify 6to4 as historic

    p.31

    Last para is very handwavey!  Device OSes are more secure these days to work in
    IPv4 hotspots too?

EV> text has shrinked and should be less handwavey

    p.33

    A campus enterprise is different - BYOD vs managed, esp. wifi/eduroam, or
    Science DMZ networks; perhaps mention RFC 7381, esp. sections 2.4, 3.2 and 4.1?

EV> of course, our very own RFC 7381 __, done

    p.35

    last para - better to omit, I think?

EV> I am afraid so... it was a nice idea though