Subject: LC comments on stable-privacy-addresses: Interface Index vs. name

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Apr 2013 09:01:16 -0500

Folks,

During IETF LC, a couple of folks noted that Interface Indexes might not
be stable.

I added some text on the subject to my working copy (mostly based on the
discussion with Brian Haberman and Mark Smith), but the issue came up
again (Tom Petch commented on the subject).

Since the raison d'etre for including the Interface Index in F() is to
differentiate between multiple interfaces connecting to the same
network, either the Interface Index or the Interface Name could be used.
So far, these are the pros/cons of each:

* Interface Index: Including this one would be ideal, since it's simply
a small number that identifies the interface, and does not really depend
on the NIC vendor, etc. However, as noted above, in some implementations
it might be unstable (i.e., vary when the system is bootstrapped).

* Interface name: This one has the pro that is stable, even on systems
in which the Interface Index is not. However, on some systems (e.g.
BSDs) the Interface name depends on the NIC vendor, which means that if
a NIC is replaced with another from a different vendor, the Interface
name is likely to change, and therefore the resulting address will change.

My take would be to replace "Interface Index" in the expression with an
abstract "Interface_ID", and then explain that "Interfae_ID" can be
either the Interface Index or the Interface name, and include some of
the text above (explaining why an implementation might want to include
one or the other -- i.e., if your Interface Indexes are stable, use
them. Else use the Interface name).

Thoughts?

Thanks!
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Christian Huitema <[email-masked]>
Date: Thu, 25 Apr 2013 15:41:36 +0000

> My take would be to replace "Interface Index" in the expression with an abstract "Interface_ID", and then explain that "Interfae_ID" can be either the 
> Interface Index or the Interface name, and include some of the text above (explaining why an implementation might want to include one or the other -- i.e., 
> if your Interface Indexes are stable, use them. Else use the Interface name).

I suggest that you just leave the choice to developers, based on the tradeoffs necessary for their particular implementations. I can see cases where I would just use the MAC address, and others where the proper tradeoff is to use nothing at all. 

Just explain what the possible objectives are:

1) Stable address until reboot, versus forever

2) Stable address as long as the same MAC is used, versus stable address even if cards are swapped

3) System design for multi homing, versus system design with just one network connection

It is unlikely that a single implementation will fit all cases.

-- Christian Huitema

---

From: Ray Hunter <[email-masked]>
Date: Thu, 25 Apr 2013 18:21:05 +0200

> them. Else use the Interface name).
Since both "Interface_Index" and "Interface name" are anyway both
implementation dependent, why would you need to precisely standardise
the exact meaning, or the exact source of the information? AFAICS this
wouldn't significantly affect inter-op, or protocol operation.

I therefore agree with your proposal that the text should define an
abstract "Interface_ID" and suggest that you define "an Interface_ID is
an implementation-dependent identifier associated with a particular
interface on the local node, which is generally invariant over the
long-term and over system reboots. The Interface_ID may be used to
assist efficient generation of unique stable-privacy-addresses,
especially in situations where multiple interfaces on a single node may
be configured using the same L3 Prefix. If the Interface_ID does change
for whatever reason, this would obviously undermine the time-invariance
of the resulting stable-privacy-addresses."

I don't think you need any more guidance than that. 

regards,
RayH

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Apr 2013 11:47:37 -0500

Hi, Ray,

> wouldn't significantly affect inter-op, or protocol operation.

Their implementation (e.g. namespace) are implementation-dependent.
Their properties may not.

I don't care about the source of information as long as it meets the
goal. Ideally, the I-D:

* Should be constant across system bootstrap sequences
* Should be different for each network interface
* Should not change when the NIC is replaced

The first to properties are needed for the "stability" properties of
this scheme. The last one is needed such that the IPv6 address doesn't
change when a NIC is replaced (I hear lots of people do not use SLAAC
because of this).

> I don't think you need any more guidance than that. 

If you say just that, many will wonder "Ok, so what should I use for the
Interface_ID?". So I'd probably list the three properties I mentioned
above, and (non-normatively) note that the Interface Index or the
Interface name could be used for this purpose...

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Apr 2013 11:50:07 -0500

Hi, Christian,

Thanks so much for your feedback! Please find my comments in-line...

On 04/25/2013 10:41 AM, Christian Huitema wrote:
>> My take would be to replace "Interface Index" in the expression
>> with an abstract "Interface_ID", and then explain that
>> "Interfae_ID" can be either the Interface Index or the Interface
>> name, and include some of the text above (explaining why an
>> implementation might want to include one or the other -- i.e., if
>> your Interface Indexes are stable, use them. Else use the Interface
>> name).
> 
> I suggest that you just leave the choice to developers, based on the
> tradeoffs necessary for their particular implementations.

Yep, that's what I meant above.

> I can see
> cases where I would just use the MAC address, and others where the
> proper tradeoff is to use nothing at all.

I believe that using the MAC address would break the useful property
that addresses do not depend on the underlying link-layer address (i.e.,
the IPv6 address does not change when the NIC is replaced). -- see my
response to Ray Hunter.

> 3) System design for multi homing, versus system design with just one

We really need:

* Stable forever
* Stable even if cards are swapped
* Multi-homing is *not* a special case

In particular, I'd really want people to know what they get when they
use this.

Cheers,

---

From: Mark Smith <[email-masked]>
Date: Thu, 25 Apr 2013 14:13:29 -0700 (PDT)

Hi Fernando,

>________________________________
> From: Fernando Gont <[email-masked]>
>To: Ray Hunter <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]>; Brian Haberman <[email-masked]>; "[email-masked]" <[email-masked]>; RJ Atkinson <[email-masked]>; t.petch <[email-masked]> 
>Sent: Friday, 26 April 2013 2:47 AM
>Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name
> 
>
>Hi, Ray,
>

I think listing those desired properties would be useful, and then describing examples of actual interface identifiers that would qualify if available e.g., persistent ifindex values or persistent interface names. 

One thing that has occurred to me is the interface identifier stability you're looking for would probably be provided by deriving the interface ID from the system connector that is used to attach the network interface to the system e.g. the PCI slot information. A swap of a failed interface, despite changing the MAC address, will retain the same interface ID. 

This gets a bit interesting when thinking about the USB NIC situation. Plugging the USB NIC into different USB slots would change the interface ID if the slot is used to assign it a persistent interface ID. OTOH, the MAC address and other properties of the USB NIC (such as USB serial number if it has one) would be constant, so they could be used to create a persistent interface ID for your purposes, despite the different USB slot used to attach it to the system. Perhaps that means different buses and/or connectors would need different policies on interface ID assignment, and that could be mentioned in your Draft.

As another example of a convention, it seems that Fedora has adopted a convention of naming wired ethernet interfaces based on whether they're attached to the motherboard (e.g, em0) or a PCI slot / port and then virtual function if it has one (e.g. p4p1), so they're persistent across boots or replacement. Yet they don't apply that to PCI attached wifi interfaces, which are still called wlanX.

You might also want to briefly cover persistent interface IDs for virtual interfaces e.g, bridge virtual interfaces. Their only constant identifier may be their name - under Linux for example, they seem to use the lowest numeric MAC address of the member interfaces, which can change if a new interface is added or the lowest MAC address interface is removed.

<snip>

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Apr 2013 20:01:43 -0300

Hi, Mark,

Thanks so much for your feedback! -- Please find my comments in-line....

On 04/25/2013 06:13 PM, Mark Smith wrote:
> 
> I think listing those desired properties would be useful, and then
> describing examples of actual interface identifiers that would
> qualify if available e.g., persistent ifindex values or persistent
> interface names.

Will do -- I'm now thinking whether I should add one subsection per
argument ("secret key, network_id", etc.), or whether I should list such
properties in the hanging-text list, or in the prose below the
expression --  thoughts?

> One thing that has occurred to me is the interface identifier
> stability you're looking for would probably be provided by deriving
> the interface ID from the system connector that is used to attach the
> network interface to the system e.g. the PCI slot information. A swap
> of a failed interface, despite changing the MAC address, will retain
> the same interface ID.

My undestanding was tht that was how interface indexes were generated --
but, aparently, they aren't.

> This gets a bit interesting when thinking about the USB NIC
> situation. Plugging the USB NIC into different USB slots would change
> the interface ID if the slot is used to assign it a persistent
> interface ID.

I'd argue that this would be a desirable property. My view is that from
a logical point of view, a NIC attached to a different port is a
different interface, and hence it should get a different IPv6 address.
(after all, if swapping a NIC should not result in a different IPv6
addresses, then this method should not try to generate the same IPv6
address when the same NIC is "detected").

> OTOH, the MAC address and other properties of the USB
> NIC (such as USB serial number if it has one) would be constant, so
> they could be used to create a persistent interface ID for your
> purposes, despite the different USB slot used to attach it to the
> system. Perhaps that means different buses and/or connectors would
> need different policies on interface ID assignment, and that could be
> mentioned in your Draft.

I'd prefer that the IPv6 address is not bound to any serial number of
MAC address. That of having the resulting IPv6 addresses being
independent of the underlying media is an interesting property.

> As another example of a convention, it seems that Fedora has adopted
> a convention of naming wired ethernet interfaces based on whether
> they're attached to the motherboard (e.g, em0) or a PCI slot / port
> and then virtual function if it has one (e.g. p4p1), so they're
> persistent across boots or replacement. Yet they don't apply that to
> PCI attached wifi interfaces, which are still called wlanX.

Yep, that's why using the interface name, *for these systems* might be
more appropriate. However, the interface names on *BSD seem to depend on
the vendor name... and hence would vary if a NIC is replaced with
another NIC from a different vendor.

> You might also want to briefly cover persistent interface IDs for
> virtual interfaces e.g, bridge virtual interfaces. Their only
> constant identifier may be their name - under Linux for example, they
> seem to use the lowest numeric MAC address of the member interfaces,
> which can change if a new interface is added or the lowest MAC
> address interface is removed.

mmm... not sure what you mean. -- Could you please elaborate?

Thanks!

Best regards,

---

From: Ray Hunter <[email-masked]>
Date: Fri, 26 Apr 2013 08:32:23 +0200

> Mark Smith <mailto:[email-masked]>
> 25 April 2013 23:13
> Hi Fernando,
>
>
>
> describing examples of actual interface identifiers that would qualify
> if available e.g., persistent ifindex values or persistent interface
> names. 
>

> This gets a bit interesting when thinking about the USB NIC situation.
> Plugging the USB NIC into different USB slots would change the
> interface ID if the slot is used to assign it a persistent interface
> ID. OTOH, the MAC address and other properties of the USB NIC (such as
> USB serial number if it has one) would be constant, so they could be
> used to create a persistent interface ID for your purposes, despite
> the different USB slot used to attach it to the system. Perhaps that
> means different buses and/or connectors would need different policies
> on interface ID assignment, and that could be mentioned in your Draft.
Slippery slope to a rat hole.

Spent 20+ years configuring various networking devices, and had various
run ins with SNMP ifName, ifIdent, cbQosObjectsIndex etc. (which are
similar concepts). IMHO There isn't a single best model.

- People might want to maintain the stable-privacy-address even though
the physical slot changes.
- An operator might want to move the configuration to another physical
or logical interface due to a fault in the original interface but
maintain config (in which case ifDescr would be a better source of
differentiation).
- An operator might want to configure up another interface that mirrors
the first for hot standby on hardware failure.
- Device may not support the concept of interface_ID.
- Interface may not have a MAC address.
- May be multiple sub-interfaces configured on one physical interface.
- Single interface devices without a removable NIC don't need to
incorporate the interface_ID at all: there's no gain (so it is only a "MAY")
- Devices without permanent storage may find it impossible to maintain
an interface_ID other than the MAC address, yet want a
stable-privacy-address.
- Devices may have their permanent storage wiped.

I still prefer the text I proposed blow (although feel free to improve it)

"an Interface_ID is an implementation-dependent identifier associated
with a particular
interface on the local node, which is generally time invariant over the
long-term and over system reboots. The Interface_ID may be used to
assist efficient generation of unique stable-privacy-addresses,
especially in situations where multiple interfaces on a single node may
be configured using the same L3 Prefix. If the Interface_ID does change
for whatever reason, this would obviously undermine the time-invariance
of the resulting stable-privacy-addresses."

>
> As another example of a convention, it seems that Fedora has adopted a
> convention of naming wired ethernet interfaces based on whether
> virtual interfaces e.g, bridge virtual interfaces. Their only constant
> identifier may be their name - under Linux for example, they seem to
> use the lowest numeric MAC address of the member interfaces, which can
> change if a new interface is added or the lowest MAC address interface
> is removed.
>
> <snip>
>
> Regards,
> Mark.
> Fernando Gont <mailto:[email-masked]>
> 25 April 2013 18:47
> Hi, Ray,
>
> Ray Hunter <mailto:[email-masked]>
> 25 April 2013 18:21
> ------------------------------------------------------------------------

---

From: t.petch <[email-masked]>
Date: Fri, 26 Apr 2013 09:16:28 +0100

---- Original Message -----
From: "Fernando Gont" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; "RJ Atkinson" <[email-masked]>;
"Brian Haberman" <[email-masked]>; "t.petch"
<[email-masked]>
Sent: Thursday, April 25, 2013 3:01 PM

> them. Else use the Interface name).

Mmm  I think that there is a tension in I-Ds such as this between the
purist IETF approach - if it does not impact interoperability, then it
has no place in an IETF RFC - and the pragmatic - end users want a
simple set of rules to follow that just work without having to
understand the ins and outs of standard making (I have met a lot of the
latter outside the IETF).  One compromise is to put the pragmatic in a
non-Normative Appendix.

'if your Interface Indexes are stable'?  I imagine most people assume
that they are (even if the choice of values made by a manufacturer seems
bizarre).  I have encountered this several times but even so, might have
forgotten if it had not surfaced on netmod last month.  So do we then
explain which systems may have unstable addresses?

So yes, I like an abstract Interface_ID but it needs some explanation,
best in an Appendix, but how far we go into unstable indices, I am
unsure.  (I am also unsure how the index value which appears in the API,
as referenced in the I-D, relates to the ifIndex value in a MIB -  I am
familiar with the latter, but do not know enough of IPv6 to know its
relationship to the former).

Tom Petch

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

---

From: Mark Smith <[email-masked]>
Date: Sun, 28 Apr 2013 21:13:26 -0700 (PDT)

Hi Fernando,

----- Original Message -----
> To: Mark Smith <[email-masked]>
> Cc: Ray Hunter <[email-masked]>; "[email-masked]" <[email-masked]>; Brian Haberman <[email-masked]>; "[email-masked]" <[email-masked]>; RJ Atkinson <[email-masked]>; t.petch <[email-masked]>
> Sent: Friday, 26 April 2013 9:01 AM

I think it might be influenced by what I've suggested below.

> but, aparently, they aren't.

I don't think it is specifically defined. For example, I understand Linux just uses an incrementing allocation counter, which is why the order of interface initialisation or insertion matters. On routers etc., this sort of scheme also seems to be common, as they also can have a command which enables persistent indexes, such that they are restored after a reboot, and typically that defaults to off. I have recently come across a scheme which doesn't seem to fit either of these though - the ifindex values are huge numbers, however they don't seem to be persistent by default, as that has to be enabled.

> address when the same NIC is "detected").

So having thought about it for a few days, I still think it would be better, by default, to try to provide a stable private address for the Interface, regardless of how it is attached to the system.

Thinking about a model, I think there are 3 components - the system, the modular network interface (hot pluggable or not) and the network it is attached to. I think IPv6 addresses are assigned at the point where the network interface connects to the network, rather than where the network interface connects to the system.

So under normal and common circumstances, if the same interface is plugged into the same network, I think it should get the same stable privacy address, regardless of whether the network interface is plugged into the same or a different system bus connector (e.g, a different USB port) at the time. I think this would be a bit more consistent with IPv6 addressing model, which says that IPv6 addresses are assigned to interfaces.

I think replacing an interface because it is faulty could be treated as a special case. Technically the interface is different, and therefore should get a different stable privacy IPv6 address. However, it is instead inheriting the stable privacy address of the interface it is replacing. I don't think this situation is necessarily indicated just by the new interface being plugged into the same system bus connector as the old one. It could be, however I think that should be enabled by a system switch, similar to how persistent ifindexes are switched on.

> independent of the underlying media is an interesting property.

What I was thinking here was that these sorts of attributes could be used to recognise when a new interface or a previously known interface is plugged into the system. They could be used as inputs (perhaps to a hash) to generate a more generic "Link Layer Interface Identifier" value (e.g. a 32 bit one) that could then be used as an input into your stable privacy address function, instead of using the ifindex. These attributes would only include those that are specific to the interface, not ones that are specific to how the interface is connected to the system, so that e.g., moving the interface to a different USB port wouldn't change the stable privacy IPv6 address.

Replacing a faulty interface would mean that the instead of the system using the Link Layer Interface Identifier value that it generates based on the new interface's attributes, it instead substitutes the faulty interface's Link Layer Interface Identifier value into the stable privacy IPv6 address function. It is likely the the system would maintain a database of known interfaces, and one of the fields would be the substitute Link Layer Interface Identifier, used if it has a value. An unknown interface would cause a new entry to be added to this database.

Globally MAC addresses by themselves theoretically should be the only attribute necessary to generate a unique Link Layer Interface Identifier, however they're not as unique in practice. So adding other available network interface similar attributes such as product ID, revision number, date of manufacture, serial number, etc., that might also be available would help recognise the same interface. 
  
> another NIC from a different vendor.

Agree. This is why I think it would be better to use attributes that are "burnt into" the network interface module itself, rather than use attributes that are either generated by the system (e.g. ifindex, interface name), or properties of how the network interface module is attached to the system.

> mmm... not sure what you mean. -- Could you please elaborate?

So these bridge virtual interfaces are the interfaces that are where the IPv6 addresses are configured/assigned, rather than the physical interfaces that are members of the bridge. They're dynamic, so they won't necessarily have the same ifindex each time, and their name may be chosen by the system operator at the time the bridge and the bridge virtual interface is created, and their MAC address can change dynamically. Is that enough of an explanation?

Best regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Apr 2013 16:40:09 +1200

On 29/04/2013 16:13, Mark Smith wrote:
...
> I don't think it is specifically defined. For example, I
> understand Linux just uses an incrementing allocation
> counter, which is why the order of interface initialisation
> or insertion matters. On routers etc., this sort of scheme
> also seems to be common, as they also can have a command
> which enables persistent indexes, such that they are restored
> after a reboot, and typically that defaults to off. I have
> recently come across a scheme which doesn't seem to fit
> either of these though - the ifindex values are huge numbers,

As far as anything is defined, they are allowed to be unsigned
32-bit integers (according to [RFC4001] and [RFC3493]).

The human-readable Zone Identifier has no length limit afaik.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Apr 2013 07:14:36 -0300

On 04/29/2013 01:13 AM, Mark Smith wrote:
>>> situation. Plugging the USB NIC into different USB slots would
>>> change the interface ID if the slot is used to assign it a
>>> persistent interface ID.
>> 
>> I'd argue that this would be a desirable property. My view is that
>> from a logical point of view, a NIC attached to a different port is
>> a different interface, and hence it should get a different IPv6
>> address. (after all, if swapping a NIC should not result in a
>> different IPv6 addresses, then this method should not try to
>> generate the same IPv6 address when the same NIC is "detected").
>> 
> 
> So having thought about it for a few days, I still think it would be
> better, by default, to try to provide a stable private address for
> the Interface, regardless of how it is attached to the system.

FWIW, with the path we're following (i.e., we describe desired
properties for the IID, but do require any specific source for it). SO
if you choose to use the MAC address as the Interface_ID, you'd get what
*you* expect. But if I choose to use the interface name as the
Interface_ID, I'd get what *I* expect ;-)

> Thinking about a model, I think there are 3 components - the system,
> the modular network interface (hot pluggable or not) and the network
> it is attached to. I think IPv6 addresses are assigned at the point
> where the network interface connects to the network, rather than
> where the network interface connects to the system.
> 
> So under normal and common circumstances, if the same interface is
> plugged into the same network, I think it should get the same stable
> privacy address, regardless of whether the network interface is
> plugged into the same or a different system bus connector (e.g, a
> different USB port) at the time.

The "problem" here is that don't have all the names/IDs we'd like. For
example, using the MAC address as the Interface_ID would do for this
purpose... but the the IPv6 address is tied to the MAC address, and
would change upon replacement of the NIC (which is generally undesirable)...

> I think this would be a bit more
> consistent with IPv6 addressing model, which says that IPv6 addresses
> are assigned to interfaces.

But from the pov of the IPv6 architecture, "interface" is the attachment
point, rather than a specific NIC...

> I think replacing an interface because it is faulty could be treated
> as a special case. Technically the interface is different, and
> therefore should get a different stable privacy IPv6 address.
> However, it is instead inheriting the stable privacy address of the
> interface it is replacing. I don't think this situation is
> necessarily indicated just by the new interface being plugged into
> the same system bus connector as the old one. It could be, however I
> think that should be enabled by a system switch, similar to how
> persistent ifindexes are switched on.

If that were the case, you'd be short-circuiting SLAAC altogether... is
that what you mean/expect?

>>> OTOH, the MAC address and other properties of the USB NIC (such
>>> as USB serial number if it has one) would be constant, so they
>>> could be used to create a persistent interface ID for your 
>>> purposes, despite the different USB slot used to attach it to
>>> the system. Perhaps that means different buses and/or connectors
>>> would need different policies on interface ID assignment, and
>>> that could be mentioned in your Draft.
>> 
>> I'd prefer that the IPv6 address is not bound to any serial number
>> of MAC address. That of having the resulting IPv6 addresses being 
> What I was thinking here was that these sorts of attributes could be
> used to recognise when a new interface or a previously known
> interface is plugged into the system. They could be used as inputs
> (perhaps to a hash) to generate a more generic "Link Layer Interface
> Identifier" value (e.g. a 32 bit one) that could then be used as an
> input into your stable privacy address function, instead of using the
> ifindex. 

The upcoming rev allows for that -- so we'd be fine.

FWIW, if you need the same NIC to always get the same address regardless
of the system port it is attached to, you should probably use the MAC
address as the Interface_ID. OTOH, if you don't want addresses to be
tied to any specific NIC, you should something else.

> Replacing a faulty interface would mean that the instead of the
> system using the Link Layer Interface Identifier value that it
> generates based on the new interface's attributes, it instead
> substitutes the faulty interface's Link Layer Interface Identifier
> value into the stable privacy IPv6 address function. It is likely the
> the system would maintain a database of known interfaces, and one of
> the fields would be the substitute Link Layer Interface Identifier,
> used if it has a value. An unknown interface would cause a new entry
> to be added to this database.

But.. if that were the goal.. why do you need the database in the first
place? You could just have a configuration knob to overwrite the "LL
Interface Identifier" with whatever you want (typically th LL address of
the NIC you're replacing).

However, the whole challenge is having this NIC-independent addresses
work automagically. -- Otherwise, you'd just configure the IPv6 address
manually, and be done with it.

Thanks!

Best regards,

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Apr 2013 15:03:41 +0000

> The "problem" here is that don't have all the names/IDs we'd like. For example, using the MAC address as the Interface_ID would do for this 
> purpose... but the the IPv6 address is tied to the MAC address, and would change upon replacement of the NIC (which is generally undesirable)...

Undesirable by whom? For a laptop, for example, the most likely cause of a MAC address change is that the user/owner used an administrative command to change it, probably in an attempt at getting privacy. Keeping the same IID would defeat the purpose.

On the other hand, if I am managing a big server, I would like to retain the same IPv6 addresses to avoid disrupting service. But then, if I want a fixed address, I would probably ensure that by configuring a fixed address, not by relying on a side effect of automatic address configuration.

-- Christian Huitema

---

From: Ray Hunter <[email-masked]>
Date: Mon, 29 Apr 2013 21:39:19 +0200

> On the other hand, if I am managing a big server, I would like to retain the same IPv6 addresses to avoid disrupting service. But then, if I want a fixed address, I would probably ensure that by co…
Right. But a bad side effect of manually configuring fixed addresses is
that you derail all of the good work around renumbering.

It might prove operationally useful to be able to configure a static
IID, but still continue to use of a variable network prefix (derived
from RA).

regards,
RayH

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Apr 2013 16:39:07 -0300

On 04/29/2013 12:03 PM, Christian Huitema wrote:
>> The "problem" here is that don't have all the names/IDs we'd like.
>> For example, using the MAC address as the Interface_ID would do for
>> this purpose... but the the IPv6 address is tied to the MAC
>> address, and would change upon replacement of the NIC (which is
>> generally undesirable)...
> 
> Undesirable by whom? For a laptop, for example, the most likely cause
> of a MAC address change is that the user/owner used an administrative
> command to change it, probably in an attempt at getting privacy.
> Keeping the same IID would defeat the purpose.

I don't think that's the rule for users, though. That said, in such
scenarios you should probably do *only* RFC4941. And, if you're
bothering to run an administrative command to change the MAC each time
you connect, why not run just another command and short-cut SLAAC to get
any address you want?

> On the other hand, if I am managing a big server, I would like to
> retain the same IPv6 addresses to avoid disrupting service. But then,
> if I want a fixed address, I would probably ensure that by
> configuring a fixed address, not by relying on a side effect of
> automatic address configuration.

There are many deployments that employ SLAAC, where address changes
would be undesirable (probably the case for most organizational networks
doing slaac).

Cheers,

---

From: Doug Barton <[email-masked]>
Date: Mon, 29 Apr 2013 13:00:48 -0700

> IID, but still continue to use of a variable network prefix (derived

I only peripherally followed the early discussion about this topic (only 
so many hours in the day). I confess that I never "got" the need for 
this, but lots of people seemed enthusiastic about it, so I put it in 
the category of things to figure out later. :)

Now that there is non-trivial pushback on the draft becoming an RFC I 
have taken another look, and I still don't get it. Let's assume that 
there are 2 broad categories that cover a statistically significant 
percentage of the possible use cases, home and business. I don't see any 
scenario where the home user would be benefited from stable privacy 
addresses beyond what 4941 already provides.

For business users, I do see a case where they would want to make sure 
that the same system always used the same address for accessing internal 
resources (auditing, accountability, etc.). The traditional answer to 
that has been to turn 4941 off, but that loses the benefits of 4941 when 
accessing outside resources. (OTOH, if the outside resources are web 
sites they already have much more sophisticated ways to track you 
besides IP address, but let's assume that 4941 is still valuable for 
sake of argument).

Assuming my use case analysis is correct (and I would not be surprised 
if it were not), it seems to me that we could accomplish both goals for 
the business case by adding a DHCPv6 option that says, "for any traffic 
on networks with these prefixes, use your 'real' address if you have 
4941 enabled."

Does that sound like a reasonable option?

Doug

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Apr 2013 17:12:07 -0300

On 04/29/2013 05:00 PM, Doug Barton wrote:
> have taken another look, and I still don't get it.

I don't see pushback, but rather feedback and request for improvements
-- which is a normal (and healthy) part of the publication process.

> Let's assume that

Please see the appendix in draft-ietf-stable-privacy-addresses. (and
keep in mind that Windows replaces the traditional slaac addresses just
to avoid address scanning attacks).

> if it were not), 

Not wanting to use temporary addresses (RC4941) does not imply that you
want to paste a super-cookie into your IPv6 addresses. Besides, as
discussed in the appendix of draft-ietf-stable-privacy-addresses, RFC
4941 and this document are, to some extent, orthogonal.

Thanks,

---

From: Doug Barton <[email-masked]>
Date: Mon, 29 Apr 2013 15:04:33 -0700

> -- which is a normal (and healthy) part of the publication process.

I'll leave it for the IESG to judge consensus of course, but I have seen 
a non-zero number of people provide "feedback" as you term it anywhere 
from "this is a bad idea," to "this probably won't work," to "It's not 
clear why this is necessary at all." The fact that they are more polite 
than I am may have allowed for that feedback to be misinterpreted however.

> to avoid address scanning attacks).

I did. I don't find any of your arguments compelling.

A.1.1
In the case of bittorrent at least I'm fairly certain that you have a 
fundamental misunderstanding as to how p2p connections are set up. But 
even if you don't, why would anyone who sets up a server-like function 
on their system have an expectation of privacy?

A.1.2
Even if all your points from A.1.1 are valid, if the attacker is on the 
same network they have other ways of tracking the targeted system. Sure, 
knowing/guessing its address would make that easier, but if you're on 
the same network with a determined attacker you've pretty much lost the 
game already. If you're not on the same network the potential for 
exploiting this knowledge is minimal given properly configured firewalls.

A.1.3
Printers? Seriously? This is a threat the IETF needs to mitigate against?

A.2
Nothing in this section is mitigated by your proposal, other than the 
discarding of certain traditionally characteristic bits, which is 
covered by another draft already.

> want to paste a super-cookie into your IPv6 addresses.

What is the intersection of the sets of people who do not want to use 
4941, but do want the privacy it provides? I'm not seeing it. As pointed 
out previously, in the case of tracking for web services your IP address 
is superfluous anyway. Do you have any other types of services in mind, 
and a description of why they can't use 4941?

> Besides, as

I'm not arguing against that. As I said, I understand the attraction of 
using the real address on your enterprise network(s), and using 4941 
outside. I just don't think your proposal accomplishes anything that 
justifies the additional complexity, if it can even work as advertised.

Doug

---

From: Brian Haberman <[email-masked]>
Date: Mon, 29 Apr 2013 18:44:59 -0400

All,
      I just want everyone to be aware that I have stopped the 
publication process on this document and sent it back to the WG.  There 
was significant feedback that I felt needed to be dealt with and that 
the resulting changes may alter the document significantly.  The author 
and the document shepherd will be setting up an issue tracker for this 
document to ensure all issues raised are addressed within the document.

      Given this, I want to make sure that everyone is aware that this 
means that the WG has to reach consensus on the contents of the document 
as if it were a new document.  Please let me know if you have any 
questions on this approach.

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Apr 2013 23:03:12 -0300

> on their system have an expectation of privacy?

If what you're trying to accomplish doesn't *require* you to make it
trivial for cooperating nodes to correlate your activities, I'm not sure
why you should.

> same network they have other ways of tracking the targeted system.

Where in the attack scenarios are we assuming that the attacker is on
the same network?

> Sure,

If you're implying a network-based firewall, you cannot rely on that. If
you're implying a host-based firewall, it's not unusual for firewalls to
respond to incoming packets (think TCP RSTs, ICMP unreach, etc.).

(And, from that pov he.. you shouldn't bother to do RFC4941, because you
should be using tor if you care about privacy...)

> Printers? Seriously? This is a threat the IETF needs to mitigate against?

Doug, that's just a simple example. Call that file server, or anything
else. The point is: why should you disclose more information than the
one you really need to disclose to achieve your desired goal?

> covered by another draft already.

Not sure what you mean. So far, when it comes to slaac, you have two
schemes implemented:

1) traditional slaac addresses embedding IEEE identifiers
2) Windows' approach of replacing the traditional slaac addresses with a
time-invariant version of RFC4941.

"1)" is vulnerable to address scanning attacks. "2)" mitigates them, but
still results in IIDs that are constant across networks, which lead to
the issues discussed in Appendix A.1 (and its subsections) of
draft-ietf-6man-stable-privacy-addresses.

> 4941, but do want the privacy it provides? I'm not seeing it.

This scheme is NOT an alternative to RFC4941. For instance, if you're
doing RFC4941, you still benefit from implementing this (it will remove
the "constant across networks" IIDs, and will also mitigate
address-scanning attacks that leverage address patterns).

> justifies the additional complexity, if it can even work as advertised.

Let me ask a different set of questions:
* What's the reason for which you want patterns on your IPv6 addresses?
* Why wouldn't you want to make IPv6 address scanning attacks unfeasible?
* Why would you want IIDs that are constant across networks?
* When you say "complexity", are you referring to "implementation
complexity"? -- does computing a hash each time you do slaac mean
"complexity" to you?

Thanks,

---

From: Tim Chown <[email-masked]>
Date: Tue, 30 Apr 2013 07:15:52 +0100

> IID, but still continue to use of a variable network prefix (derived

As per http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02 ?

Tim

---

From: Ray Hunter <[email-masked]>
Date: Tue, 30 Apr 2013 11:05:57 +0200

Tim Chown wrote:
> On 29 Apr 2013, at 20:39, Ray Hunter <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Christian Huitema wrote:
>>>> this
>>> Undesirable by whom? For a laptop, for example, the most likely
>>> cause of a MAC address change is that the user/owner used an
>>> administrative command to change it, probably in an attempt at
>>> getting privacy. Keeping the same IID would defeat the purpose.
>>>
>>> retain the same IPv6 addresses to avoid disrupting service. But
>>> then, if I want a fixed address, I would probably ensure that by
> As
> per http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02
> ?
>
> Tim

I hadn't seen that particular draft before, but yes. Of course you'd
probably also want to be able to configure IID based ACL's, static
routes etc. where the prefix was auto-prepended to the static IID
portion of the config. Don't want to hijack the thread, but I see no
fundamental reason why your draft couldn't be combined with Fernando's work.