Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-15.txt

[Brian E Carpenter <[e-mail]>]

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