Re: draft-gont-6man-managing-privacy-extensions-00.txt

[Fernando Gont <[e-mail]>]

Hi, James,

On 09/03/2011 04:08 p.m., james woodyatt wrote:
> About the H-bit in the PIO it proposes, the draft says this:
> 
> When set, this bit indicates that hardware-derived addresses SHOULD
> be used when configuring IPv6 addresses as a result of Stateless
> Address Autoconfiguration.  When not set, this bit indicates that
> Privacy Extensions SHOULD be enabled when configuring IPv6 addresses
> as a result of Stateless Address Autoconfiguration
> 
> Which makes the bit worse than useless.  If the PIO contains A=1,
> then both EUI-64 and privacy IID are eligible under the current
> regime, but this draft says only that one or the other SLAAC
> alternative SHOULD be used depending on the state of the bit, without
> explicitly saying whether the complementary alternative SHOULD NOT be
> used.
> 
> I'm not sure if the intent is to make a signal for hosts that network
> administration regards any particular SLAAC alternative as NOT
> RECOMMENDED, but if it is, then the draft should explicitly say so.

Will do. The idea is that there's a policy that SHOULD be used, with the
others being "NOT RECOMMENDED".


> Of course, if the draft were to changed to do that, then I would
> lodge the same complaints that I lodged previously against
> I-D.yhb-6man-ra-privacy-flag... for the same reasons.

I will dig the archives. :-)  However, as noted in other posts, this is
not about "disabling privacy addresses", but about allowing admins to
communicate policies to hosts. i.e., this mechanism might be used for
*enabling* privacy addresses (rather than disabling them), too.



> This draft has a long struggle ahead of it, if you ask me.

Comments on specific issues would be very welcome, such that we can work
on fixing/improving them. ;-)

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1