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


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 and amend 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 such objections should have been lodged against RFC7217.










--Charlie




























Sent from 

Outlook