Subject: draft-yhb-6man-ra-privacy-flag-02

From: "Yu Hua bing" <[email-masked]>
Date: Tue, 8 Mar 2011 23:09:46 +0800

Hi, I have submit draft-yhb-6man-ra-privacy-flag-02. The problem to 
   be solved is as follows:

   In some sites, the network administrators want to deploy stateless 
   address autoconfiguration, and just permit the hardware-derived 
   addresses to communicate with the Internet.They will do as follows:

   (1)Bind the MAC address and the hardware-derived address for each 
   host on the access switches.Because the temporary addresses are 
   variable, it is impossible to bind the MAC address and the temporary 
   address.

   (2)Disable the temporary addresses on each host.Why?Because the 
   temporary addresses may be preferred as the source of the outbound 
   IPv6 traffic.Now it is difficult to disable the temporary addresses 
   on all the hosts in the site,because:

   (2.1)The network administrator has to notify every one to disable the 
   temporary adrresses.In the enterprise with thousands of employees, it
   is very difficult to ensure that every one will see the notice.

   (2.2)Many people are not familier with the host operation system, 
   they don't know how to disable the temporary addresses.    
   
   This document tries to provide a solution to these network 
   administrators,and they can specify whether the prefixes can be used
   to generate the temporary addresses.

  Now we can provide two solutions to the network administrators:
  (1) SLAAC + bind the MAC address and the  hardware-derived address on the access switch + disable the temporary addresses
  (2) DHCPv6 + DHCPv6 snooping
  The first solution is cheaper, and is easier to deploy.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 08 Mar 2011 10:35:36 -0500

>   The first solution is cheaper, and is easier to deploy.

How is option 1 cheaper if you need all your hosts to be updated (at
some point) to recognize this new flag?  I understand the desire to
offer a SLAAC-based approach that mimics the type of control one would
have with DHCP-based address assignment, but the cost argument in this
case does not seem like a valid argument.

Another possible approach is to increase the preference of
public/permanent addresses in the address selection policy table (RFC
3484 and its update 3484bis). That would effectively preclude hosts from
using privacy addresses.  Of course, there is still the issue as to
*how* the network operator disseminates the policy table...

Regards,
Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 9 Mar 2011 07:19:00 +1030

On Tue, 8 Mar 2011 23:09:46 +0800

>    addresses to communicate with the Internet.They will do as follows:
<snip>
>   The first solution is cheaper, and is easier to deploy.

You'd be better off focusing on address usage and recording
mechanisms, which will not require changes to end-nodes, would be
compatible with all current addressing methods (i.e. SLAAC, DHCPv6,
static), and would also inherently accommodate any future
addressing methods (how ever unlikely that may be of occuring). That
will be the cheapest and most effective solution to your problem.

Neighbor caches, Duplicate Address Detection and Neighbor
Unreachability Detection create enough externally visible information
and maintain enough state to track appearance, continued existence and
the disappearance of nodes using IPv6. Develop a mechanism that
externally records the state transitions you're interested in, and I
think you'd have an adequate solution to your problem without having
develop additional IPv6 related addressing mechanisms and then having
to deploy them to end-nodes on a wide scale.
 
http://ndpmon.sourceforge.net/ is an example of the sorts of things
people are already using external observance of ND transactions for. It
can already record new station, new IPv6 Global Address and new
Link Local Address. It probably wouldn't be too hard to make it also
record when stations disappear. Ideally it'd be best to utilise the
underlying operating system's existing NUD mechanism to do this
tracking.

Regards,
Mark.

---

From: huabing yu <[email-masked]>
Date: Wed, 9 Mar 2011 09:24:57 +0800

2011/3/8 Brian Haberman <[email-masked]>

> >   (1) SLAAC + bind the MAC address and the  hardware-derived address on
> the access switch + disable the temporary addresses
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

 We can't only think about now. We should think about the future.For IPv6,
the path is long.
  I think an idea should be adopted if it is helpful in the future.

 Your proposed approach has a flaw: if the application explicitely specifies
the privacy address
  as the source, the address selection policy table will not work. It is
best that the host disables
  the privacy addresses.

---

From: huabing yu <[email-masked]>
Date: Wed, 9 Mar 2011 09:29:54 +0800

2011/3/9 Mark Smith <[email-masked]>

> underlying operating system's existing NUD mechanism to do this

  In some sites, the network administrators want to prevent the host from
using any IPv6 address,
  like DHCPv6 plus DHCPv6 snooping. Your method can't.

---

From: Mark Smith <[email-masked]>
Date: Wed, 9 Mar 2011 19:48:32 +1030

On Wed, 9 Mar 2011 09:29:54 +0800

<snip>

>   like DHCPv6 plus DHCPv6 snooping. Your method can't.

So, looking at the text at the top of the draft (although this is from
the -01 version, as I can't seem to find the -02 one), where you
present your use case -

"when the network is in trouble,it is difficult to find out
which host is attacking the other hosts."

it seems your real and fundamental goal is to be able to track the
mappings between MAC addresses and corresponding IPv6 addresses. Since
privacy addresses naturally makes that harder, and the decision to use
that is in the control of the end-host, you think the way to achieve
that auditability is to provide a mechanism to suppress privacy them.

I think you should sit back and think about the problem some more. The
people who are likely to execute these attacks will have also have
a motive to (a) choose an operating system where the tools to execute
these attacks are more commonly available and (b) as that operating
system is likely to be an open source one, modify the kernel, or
install somebody else's kernel patch that ignores any "disable privacy"
addresses mechanisms you manage to get deployed. You can't completely
trust the end-host to follow mechanisms that aren't in its owner's
interests.

I think you'll be more successful at achieving your fundamental goal by
observing and recording their IPv6 address use rather than trying to
control it with mechanisms they have the ability to disable.

Regards,
Mark.

---

From: "Yu Hua bing" <[email-masked]>
Date: Wed, 9 Mar 2011 21:43:54 +0800

--------------------------------------------------
From: "Mark Smith" <[email-masked]>
Sent: Wednesday, March 09, 2011 5:18 PM
To: "huabing yu" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-yhb-6man-ra-privacy-flag-02

> control it with mechanisms they have the ability to disable.

I have submit draft-yhb-6man-ra-privacy-flag-02 by email to 
[email-masked].
IETF didn't publish it. Please wait.

I described the problem to be solved in the email 
"draft-yhb-6man-ra-privacy-flag-02".
I just want to cite an example to let you realize the value of the flag.Some 
people may
 not like it, but the other people may like it.

Yu Hua bing

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Mar 2011 07:41:48 +1300

On 2011-03-09 22:18, Mark Smith wrote:
...
> control it with mechanisms they have the ability to disable.

Since we defined privacy addresses specifically so that individual
hosts could reduce their traceability, it seems very controversial
to do anything that harms that ability.

We did this, people will recall, as a direct result of public concern
about traceability based on CPU serial numbers and/or MAC addresses.

That refers to traceability on the open Internet, not traceability
on the LAN. So indeed, as Mark says, this can be solved locally
by MAC logging (from DHCP or ND). That will not remove the ability
to use privacy addresses beyond the LAN.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 9 Mar 2011 11:00:35 -0800

> to use privacy addresses beyond the LAN.

+1

Bob

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Mar 2011 07:41:32 +1030

On Thu, 10 Mar 2011 07:41:48 +1300

> to use privacy addresses beyond the LAN.

Actually, one of the reasons I've been thinking about this "ND logging"
recently, before these privacy proposals came up, is because of the
criticisms about both stateless and stateful addressing methods
existing in IPv6.

The common argument from the "stateful-only crowd" seems to be that
they need to have a log of IPv6 address/MAC addresses for audit
purposes, and therefore think they need to have stateful, database
driven addressing to do that, probably because that is how it has
been done in IPv4. I've thought that SLAAC with more detailed ND state
logging, triggered by NUD state changes, would provide them with what
they need, without requiring the additional software infrastructure and
state maintenance that stateful DHCPv6 addressing involves. Although
stateful DHCPv6 clients are becoming far more widely available, all
IPv6 end-nodes are at minimum going to support SLAAC.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Mar 2011 15:05:47 +1300

> IPv6 end-nodes are at minimum going to support SLAAC.

Not to mention that such a logging mechanism will detect any hosts that
are misbehaving by simply giving themselves arbitrary addresses, which as
far as I can see can't be prevented in the general case.

     Brian

---

From: [email-masked]
Date: Thu, 10 Mar 2011 08:45:54 +0100 (CET)

> been done in IPv4.

In our (service provider) case the basic requirement is to be able to
associate a dynamic IPv6 address with a specific *customer*.

We're not really interested in the MAC address other than the fact
that customer support sometimes finds it useful to look at the OUI and
tell the customer "you need to restart your XX wireless router because
..."

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Mar 2011 22:36:23 +1030

> associate a dynamic IPv6 address with a specific *customer*.

Can't you use RADIUS for that? I'm working in a SLAAC
environment for SP customers over PPP/PPPoE or L2TP, and RADIUS is
reporting everything we're interested in knowing, including username,
PPP IPV6CP IIDs, chosen dynamic prefixes for the PPP session and dynamic
delegated prefixes if they're requested and the customer falls in that
service type.

---

From: [email-masked]
Date: Thu, 10 Mar 2011 13:31:58 +0100 (CET)

> delegated prefixes if they're requested and the customer falls in that

Sure we can. If we redo our DHCP infrastructure to use Radius instead.
It is a major change, and we don't really want to do it unless we
absolutely have to.

There are plenty of *other* bumps in the road on our way to IPv6. I
see no need to introduce more of these than necessary.

---

From: Mark Smith <[email-masked]>
Date: Sun, 13 Mar 2011 12:00:59 +1030

> It is a major change, and we don't really want to do it unless we

Where did I say you had to change what you already had and were
satisfied with? All I've said is that I think SLAAC plus more
detailed ND state logging would be functionality equivalent to
what those who advocate stateful DHCPv6 addressing usually
state they require, and that is generally in the (unstated) common case
of a LAN environment, although it may also be applicable in an SP/CPE
scenario. I think if the choice between SLAAC + more detailed router ND
state recording verses stateful DHCPv6 was commonly available, the SLAAC
option would be the most likely choice, due to more (and most likely
all) IPv6 end-nodes supporting SLAAC (in the common case context of a
LAN environment).

> see no need to introduce more of these than necessary.

Maintaining state costs CPU, RAM, and potentially disk space and
network traffic. Reducing the amount of state and/or gaining more value
out of existing essential state seems to me to be a worthy goal. In
practical terms, I think reducing the end-node requirement for stateful
DHCPv6, and leveraging the existing and essential NUD state to achieve
the same functional results for most use cases of stateful DHCPv6 would
be something worth aiming for.