Brian,
> On Mar 9, 2019, at 1:55 PM, Brian E Carpenter <[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];… +1 > >> 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! RFC4864 also describes this. Bob > >> 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
