Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85102128E18; Fri, 18 Nov 2016 20:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 OsmtMzN0uokR; Fri, 18 Nov 2016 20:02:58 -0800 (PST) Received: from SNT004-OMC3S17.hotmail.com (snt004-omc3s17.hotmail.com [65.55.90.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029D61293F9; Fri, 18 Nov 2016 20:02:57 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.55.90.137]) by SNT004-OMC3S17.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 18 Nov 2016 20:02:57 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7fb9NC9MyIioUWFYHnHgWDrcdIJAg5NoNXa0c0zlmX4=; b=S8GtG1QI2sMBELPQt6ojDQayZm6UKFNvpfCJngUOuFA6bW534z94miHnxH/v/vWxRU7bzowjkHQCY6ujCmNubn7lGyGeVPc4U3xGle5lAYDA22lcao9XEoeS3eHlhXHEhrX+u+LfR7zzKZb8t18TLJ4+IU8dCDrIxzfDnFDlNLy3VWb/yLoV/ZLerkZ0gSBMz21+V/jaN/XEVZLikLIcsVNRFULpgbB0fhqX8lh/ILTvNJ/+jPfjN2oAEPrbhZJ46gvnxu7/TB+naXzoyGe9+1KvoQa/03t86Y26LcfN5cZpP7yBYjnasyZirlo6WTyYCvMY25hwfSNQpbQyavQtHg== Received: from CY1NAM02FT034.eop-nam02.prod.protection.outlook.com (10.152.74.53) by CY1NAM02HT157.eop-nam02.prod.protection.outlook.com (10.152.75.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.5; Sat, 19 Nov 2016 04:02:56 +0000 Received: from CY4PR17MB0997.namprd17.prod.outlook.com (10.152.74.51) by CY1NAM02FT034.mail.protection.outlook.com (10.152.75.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.4 via Frontend Transport; Sat, 19 Nov 2016 04:02:56 +0000 Received: from CY4PR17MB0997.namprd17.prod.outlook.com ([10.173.181.7]) by CY4PR17MB0997.namprd17.prod.outlook.com ([10.173.181.7]) with mapi id 15.01.0721.017; Sat, 19 Nov 2016 04:02:56 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , 'The IESG' , "draft-ietf-6man-default-iids.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-6man-default-iids-16 Thread-Index: AQHSQhe/hqED3+8kAUeTD8JTC7NMKQ== Date: Sat, 19 Nov 2016 04:02:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:7421; Count:37 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [iMgBa61nNauVPoY7DNTfm9FDNSxjrV6w] x-incomingheadercount: 37 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; CY1NAM02HT157; 5:IPb8/moFDZcvauy+T+bqo/KRoaDFv3Nxj7rTPRfFG6ZC7km/UuXSe9xG3Y3S1jhNpNtiwScHtSOlVhJaxZg9UNyUaid9e9HgtCHUE4sXUDWLwElmPghXkvBgn9akBW0d1JXFjvDUfio+h8vLT09uKQ==; 24:HiA6+8KAwyb9HPl46HRw7wbagEOv1s66UaPUa/aSYsq0akpPpdPYXrI82p7c/aj1QHA31SP96lVNe26qizViaTeleR8yEHUu9/lG+/Zo70w=; 7:+TWRNSWijCB6mcVRtZf/Fx6WbQMN4KwJUME2VY5lb7aidCuw0BejeZoXpzn+twVQEgx/8SvaUGZGbc9gUDzn5C6/Q+Fmtx/j8CddAMRQ1gyvYAi66GAkZikeNwkeSbMiwjcZO/qakeOOZ2pA3ZFJqsDOuKqsQqhEvpiQ8cJYg0wKLy2EXL+tTsAQTWs0KhtfNti7VvlbZ5kSxNBLzxzRJfljpjmxkPRfSLZab3Kj9qFT6bF8rrnFR5RMGUf5zDrQvZnAhfXeiv0lvo6+yu1Nv+Mmq4HW8SVgosc712gv4vLzK/tmzHDWl0GkAGyb8uRj5T7mGmE4YUJdC32nxg1bnk/W0ZAyRnd+9LBhYDDvmS4= x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1NAM02HT157; H:CY4PR17MB0997.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 20b4ead4-c21c-4025-4a44-08d41030f16d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(1603103113)(1603101340)(1601125047); SRVR:CY1NAM02HT157; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:CY1NAM02HT157; BCL:0; PCL:0; RULEID:; SRVR:CY1NAM02HT157; x-forefront-prvs: 0131D22242 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR17MB09978ED339434C8F19ED4A5FDFB30CY4PR17MB0997namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2016 04:02:55.9477 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT157 X-OriginalArrivalTime: 19 Nov 2016 04:02:57.0528 (UTC) FILETIME=[CFCFBF80:01D24219] Archived-At: Subject: [secdir] Secdir review of draft-ietf-6man-default-iids-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 04:03:00 -0000 --_000_CY4PR17MB09978ED339434C8F19ED4A5FDFB30CY4PR17MB0997namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. This document is: Ready This is a bookkeeping document with no technical content. At issue is how t= o pick the low order eight bytes of IPv6 addresses. The original vision was= to use the six bytes MAC address or the eight bytes from some other MAC ad= dress assignment mechanism so that addresses could be unique without any sp= ecial configuration. That approach has been problematic. In an increasingly= virtualized world, more and more entities need IPv6 addresses that don't h= ave physical adaptors from which to get MAC addresses. Worse, privacy enthu= siasts believe it will leak too much information about who you are if you u= se the same low order bits in an IPv6 address when connecting to different = network connection points. RFC7217 specified an alternate means for choosing the low order 8 bytes of = IPv6 addresses that will generate consistent addresses when connecting to t= he same network connection point but different addresses when connecting di= fferent ones. There is a growing consensus that this is a better default be= havior. Unfortunately, there are lots of existing RFCs that include contrary advice= ... that still recommend the older mechanism. So this document formally upd= ates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146= , RFC3572, RFC4291, RFC4338, RFC4391, RFC5072, and RFC5121 to reflect the new advice. = If we can do this instead of going back and updating all of those documents= , then there is an administrative savings. If we're also going to go back a= nd amend each of those documents, then I'm not sure what this document is f= or. In any case, there should be no security objections to this document. Any s= uch objections should have been lodged against RFC7217. --Charlie Sent from Outlook --_000_CY4PR17MB09978ED339434C8F19ED4A5FDFB30CY4PR17MB0997namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. Thes= e comments were written primarily for the benefit of the security area dire= ctors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document is: Ready

This is a bookkeeping document with no technical content. At issue is ho= w to pick the low order eight bytes of IPv6 addresses. The original vision = was to use the six bytes MAC address or the eight bytes from some other MAC= address assignment mechanism so that addresses could be unique without any special configuration. That app= roach has been problematic. In an increasingly virtualized world, more and = more entities need IPv6 addresses that don't have physical adaptors fr= om which to get MAC addresses. Worse, privacy enthusiasts believe it will leak too much information about who yo= u are if you use the same low order bits in an IPv6 address when conne= cting to different network connection points.


RFC7217 specified an alternate means for choosing the low order 8 bytes = of IPv6 addresses that will generate consistent addresses when connecting t= o the same network connection point but different addresses when connecting= different ones. There is a growing consensus that this is a better default behavior.


Unfortunately, there are lots of existing RFCs that include contrary adv= ice... that still recommend the older mechanism. So this document = formally updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572,

RFC4291, RFC4338, RFC4391, RFC5072, and RFC5121 to reflect the new advice. If w= e can do this instead of going back and updating all of those documents, th= en there is an administrative savings. If we're also going to go back and a= mend each of those documents, then I'm not sure what this document is for.=


In any case, there should be no security objections to this document. Any suc= h objections should have been lodged against RFC7217.<= /font>


--Charlie





Sent from Outlook=

--_000_CY4PR17MB09978ED339434C8F19ED4A5FDFB30CY4PR17MB0997namp_--