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,
-- 
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