Skip to main content

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

Request Review of draft-ietf-6man-default-iids
Requested revision 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 (Shucheng) LIU
I-D 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
Request Last Call review on draft-ietf-6man-default-iids by Security Area Directorate Assigned
Reviewed revision 16
Result Ready
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