Brian and Bob, First of all, thank you for the quick review. And especially, the text around EUI-64 & SLAAC which we, the authors, will gladly accept.
In order to progress with this draft, the authors will issue today a -16 where the ULA section will simply be reduced to mention the ULA considerations draft. With this, we hope to remove the last (?) blocking factor for this OPsecv6 draft. Regards -éric On 09/03/2019, 22:56, "OPSEC on behalf of Brian E Carpenter" <[email protected] on behalf of [email protected]> wrote: Hi, A few comments. (Note that I am not on the opsec list, so please CC me on any replies.) > 2.1.2. Use of ULAs .... > It is tempting to think that ULAs could be useful for infrastructure > hiding as described in [RFC4864];... That's a very strange choice of words, and ignores the actual argument for this choice, which is that internal communications using ULAs are doubly protected from accidental external visibility. If you want to say that RFC4864 was wrong, please argue that explcitly. Otherwise please be neutral, e.g.: ULAs could be used for infrastructure hiding as described in [RFC4864];... > It is recommended to consider filtering packets with ULA source > addresses or ULA destination addresses at the domain boundary. Actually RFC4193 is already stronger than that. Filtering ULA routes is a "must", and filtering packets containing ULA source or destination is a "should" (unless explicitly configured otherwise). I think you should not weaken this here! > 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC > > Historically stateless address autoconfiguration (SLAAC) relies on > the automatically generated EUI-64 address,which together with the > /64 prefix makes up the global unique IPv6 address. That's inaccurate. Try: Historically, stateless address autoconfiguration (SLAAC) relied on an automatically generated 64 bit interface identifier (IID) based on the EUI-64 MAC address, which together with the /64 prefix makes up the globally unique IPv6 address. .... > As [RFC4941] privacy extension addresses could also be used to > obfuscate some malevolent activities (whether on purpose or not), > specific user attribution/accountability procedures must be put in > place as described in section Section 2.6. That "must" is a bit strange. It seems too much to say "MUST", so why not make it "SHOULD"? Regards Brian Carpenter _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
