On 04/29/2013 01:13 AM, Mark Smith wrote:
>>> 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").
>> 
> 
> 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 
>> 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. 

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,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to