Subject: RE: draft-yhb-6man-ra-privacy-flag-01

From: RJ Atkinson <[email-masked]>
Date: Fri, 4 Mar 2011 10:32:56 -0500

Some of my clients operate pretty large enterprise networks.
Within those networks, they want to avoid using the so-called
"privacy IPv6 addresses" because of requirements (e.g. the US
HIPAA law) to be able to audit their network, including 
auditing precisely which devices are present.

IPv6 SLAAC works fine for this, provided that the so-called
IPv6 privacy addresses are not used.  DHCPv6 also could work, 
but has substantial deployment costs, including recurring 
operational costs, making it a visibly more expensive
deployment approach than SLAAC.

So at least some of my enterprise network clients would be
very interested in seeing a SLAAC flag be created to inform
end systems that the so-called IPv6 privacy addresses 
are NOT to be used with a given routing-prefix advertised
via IPv6 RA messages.

So I think it would be valuable for the WG to explore 
the ideas of this I-D.  The document itself is clearly
not yet mature, however.

1) The "Introduction" of this I-D needs additional editorial 
   work to clarify the broader range of reasons (some examples
   are provided above) why this flag might be useful within
   some IPv6 deployments.  

2A) The "Security Considerations" needs to include a thorough 
   and serious discussion of the differences in user privacy 
   expectations between corporate/enterprise network deployments 
   and home/residential network deployments.  

2B) Within home/residential deployments, use of privacy 
   addressing ought NOT be disabled operationally because there 
   is a reasonable expectation of privacy when a user is on 
   his/her home/residential network.  This advice needs to be 
   clearly documented within this I-D in the Security Considerations 
   section.

One last thing.  A number of my clients have a very crisp perception
that the ongoing IETF IPv6 WG activity to add/change specifications 
means that "IPv6 is NOT yet ready to deploy operationally".   

I think this perception is pretty widespread.  Reducing the rate
of change/addition to the IPv6 specification set generally would be
helpful to encouraging IPv6 deployment.  I'm not suggesting zero
changes/additions, but instead suggesting that the WG carefully
consider whether a proposed change/addition is really useful and
whether it needs to be undertaken now/soon as part of considering 
each proposed change/addition to the IPv6 specifications.  
A lower rate of change/addition will tend to speed IPv6 deployment,
in my estimation.

Yours,

Ran

---

From: james woodyatt <[email-masked]>
Date: Fri, 04 Mar 2011 07:55:23 -0800

On Mar 4, 2011, at 7:32 AM, RJ Atkinson wrote:
> 
> [...] but instead suggesting that the WG carefully consider whether a proposed change/addition is really useful and whether it needs to be undertaken now/soon as part of considering each proposed change/addition to the IPv6 specifications. [...]

And on that note, let me hereby register my opposition to the adoption of this draft as a working group item on the grounds that this change is not sufficiently useful to justify such a late change to the core protocol specification.  Enterprise networks should expect to pay for the proper costs of auditing, and if that includes the cost of requiring every host to use DHCPv6 to obtain both temporary and persistent addresses, then that's an adequate solution to the auditing problem without requiring any change to the core specifications.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Sander Steffann <[email-masked]>
Date: Fri, 4 Mar 2011 17:01:23 +0100

Hi,

> And on that note, let me hereby register my opposition to the adoption of this draft as a working group item on the grounds that this change is not sufficiently useful to justify such a late change…

+1

And existing hosts/implementations will ignore the new flag anyway, so how can an enterprise 'guarantee' that privacy extensions will not be used? My feeling is that this I-D will only cause confusion without solving the problem.

- Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Mar 2011 17:23:57 +0100 (CET)

> And existing hosts/implementations will ignore the new flag anyway, so how can an enterprise 'guarantee' that privacy extensions will not be used? My feeling is that this I-D will only cause confus…

I also agree. Let's not change RA more than is absolutely needed. The 
problem description sounds exactly like what DHCPv6 was designed to solve. 
If you need to track what IPs are used at a given time and by whom, SLAAC 
is not the way to go.

The proposed solution doesn't solve the problem described.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 4 Mar 2011 12:21:57 -0500

On 04  Mar 2011, at 11:01 , Sander Steffann wrote:
> And existing hosts/implementations will ignore the new flag anyway,
> so how can an enterprise 'guarantee' that privacy extensions
> will not be used?

As with any proposed change/addition to existing IPv6 specs,
implementation support appears over time.  

While any proposed change/addition is not available universally 
on Day 1, it is also likely that an adopted change/addition
will appear in various products over time.

> My feeling is that this I-D will only cause confusion
> without solving the problem.

Noted. 

Of course, that argument (i.e. not all implementations 
will support feature X on day 1) equally can be applied 
to all proposed IPv6 specification additions/changes.

So my takeaway from your note (and jhw's note :-) is that 
you all are among the folks who would like to see IPv6 specs 
freeze more than they have so far.

:-)

Cheers,

Ran

---

From: "t.petch" <[email-masked]>
Date: Fri, 4 Mar 2011 18:11:31 +0100

----- Original Message -----
From: "Mikael Abrahamsson" <[email-masked]>
To: "6MAN" <[email-masked]>
Sent: Friday, March 04, 2011 5:23 PM

> >> And on that note, let me hereby register my opposition to the adoption of
this draft as a working group item on the grounds that this change is not
sufficiently useful to justify such a late change to the core protocol
specification.  Enterprise networks should expect to pay for the proper costs of
auditing, and if that includes the cost of requiring every host to use DHCPv6 to
obtain both temporary and persistent addresses, then that's an adequate solution
to the auditing problem without requiring any change to the core specifications.
> >
> > +1
> >
> > And existing hosts/implementations will ignore the new flag anyway, so how
can an enterprise 'guarantee' that privacy extensions will not be used? My
feeling is that this I-D will only cause confusion without solving the problem.
> If you need to track what IPs are used at a given time and by whom, SLAAC

I agree.

After how ever many years it is, we really ought to be rolling something out
be it ever so slightly imperfect.

Who knows, we might need to use it in anger in a large scale deployment:-)

Tom Petch

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Karl Auer <[email-masked]>
Date: Sat, 05 Mar 2011 09:35:44 +1100

> are NOT to be used with a given routing-prefix advertised

Even if the router issued such a flag, any host would still be at
liberty to use any address it liked. The router flags, as I read the
RFCs anyway, are more in the nature of hints. Short of not issuing RAs
at all.

For example, nothing stops me configuring a static address, even though
my router is issuing prefix information - in fact, even if it doesn't
issue any prefix information at all (which is pretty much where IPv4 is
at). And I can still issue a DHCP SOLICIT, even if the router didn't
tell me to (though how far it would get is another story).

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

---

From: Karl Auer <[email-masked]>
Date: Sat, 05 Mar 2011 09:38:49 +1100

> If you need to track what IPs are used at a given time and by whom, SLAAC 

Well, if SLAAC is using the MAC addresses, it's pretty useful. But
neither SLAAC nor DHCP *really* solve it. Any host can take any address
in the right prefix and (modulo snooping and other switch/router
features) be active in the network. That is, both SLAAC and DHCP really
only allow "tracking" of well-behaved hosts.

> The proposed solution doesn't solve the problem described.

No, it doesn't.

Regards, K.