Last Call Review of draft-ietf-6man-default-iids-16

Request Review of draft-ietf-6man-default-iids
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-12-02
Requested 2016-11-17
Authors Fernando Gont, Alissa Cooper, Dave Thaler, Will LIU
Draft last updated 2016-11-24
Completed reviews Secdir Last Call review of -16 by Charlie Kaufman
Genart Last Call review of -16 by Roni Even
Intdir Early review of -15 by Jouni Korhonen (diff)
Opsdir Last Call review of -16 by Sarah Banks
Assignment Reviewer Charlie Kaufman 
State Completed
Review review-ietf-6man-default-iids-16-secdir-lc-kaufman-2016-11-24
Reviewed rev. 16
Review result Ready
Review completed: 2016-11-24


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 comments 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 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 approach has been problematic. In an increasingly virtualized world, more and more entities need IPv6 addresses that don't have physical adaptors from which to get MAC addresses. Worse,
 privacy enthusiasts believe it will leak too much information about who you are if you use 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 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 advice... that still recommend the older mechanism. So this document

formally updates




























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 and amend each of those documents, then
 I'm not sure what this document is for.

 any case, there should be no security objections to this document. Any such objections should have been lodged against RFC7217.


Sent from