Subject: Re: draft-yhb-6man-ra-privacy-flag-00

From: RJ Atkinson <[email-masked]>
Date: Thu, 24 Feb 2011 14:03:29 -0500

On 24 Feb 2011 at 09:35:12 -0800, James Woodyatt wrote:
>> On Feb 24, 2011, at 6:19 AM, Yu Hua bing wrote:
>> Hello, what do you think of this draft? 
>> http://datatracker.ietf.org/doc/draft-yhb-6man-ra-privacy-flag/
> 
> 
> I don't see why using A=0 in the PIO is insufficient for this purpose.

User sites have a very wide range of deployment models.
The best way to deploy IPv6 is to enable users to deploy in a manner
suitable to their own local needs, rather than restrict them arbitrarily.

There exist a number of sites that want to enable SLAAC, but do NOT enable/
permit deployment of the (psuedo-)privacy extension.  A common reason is 
to reduce operating costs (e.g. eliminate DHCP server/ops costs, reduce
capital costs, reduce troubleshooting costs,  reduce auditing costs).

There are also sites that want to enable SLAAC and also enable the
(pseudo-)privacy extension.  

(Not relevant here, but there are also sites that want SLAAC with DHCP 
available for extra info, DHCP and NOT SLAAC, and so on. :-)

The existing "A=0" bit is not sufficient for all cases, 
as you seem to acknowledge later on, no matter how one interprets it.

> That said, I also think a huge flaw in the draft is that existing hosts
> interpret the currently unused and reserved bit in the reverse sense,
> i.e. that privacy addresses are allowed when the value is zero.

Interesting.  Examples of such hosts using a reserved bit 
for that specific meaning ?

> If you want to propose a flag that expressly allows SLAAC without RFC 4941
> privacy addresses, then the sense of the bit needs to be reversed.  For example,
> the conceptual variable would be DisablePrivacyAddrs, and the bit in the PIO
> would be named the NoPrivacy flag.

It is equally valid to have a conceptual variable EnablePrivacyAddrs,
with the bit being named the Privacy flag.

Yours,

Ran Atkinson