On May 19, 2013, at 13:16 , Fernando Gont <[email protected]> wrote: > On 05/19/2013 04:31 PM, james woodyatt wrote: >> I have a problem with the following set of requirements: >> >> The Net_Iface is a value that identifies the network interface for >> which an IPv6 address is being generated. The following properties >> are desirable for the Net_Iface: >> >> o it MUST be constant across system bootstrap sequences and other >> network events (e.g., bringing another interface up or down) >> >> o it MUST be different for each network interface >> >> Some hosts have dynamic logical network interfaces (distinguishable >> from physical interface), which are created every time the host joins >> a network, and destroyed when the host separates from a previously >> joined network. Examples are typically interfaces that involve >> signaling systems, point-to-point connection semantics for the link >> layer, e.g. virtual private networks, automatic tunnels, et cetera. >> >> According to these requirements, such hosts MUST NOT reuse previously >> generated stable privacy addresses when joining the same network with >> a new logical interface. That seems counter to the goal of this >> standard. > > I'm not sure I follow... The requirement is that you address changes > when you move from one network to another. The only requirement for > "Net_Iface" must be different for different network interface is that > DAD failures are avoided (i.e., you don't have any two interfaces > deterministically getting the same address).
If avoiding DAD failure is the goal, then the second clause is overly restrictive. It should suffice that the value of Net_Iface is different for each network interface in *simultaneous* use. >> I think hosts need some latitude in these requirements to allow for >> temporally different network interfaces associated with the same >> network service from the host's view to have the same identity for >> the purpose of generating stable privacy addresses. > > If you use the interface index for Net_Iface, you'd probably get exactly > this. Same thing if you use the interface name (these virtual interfaces > are likely to get the same names when they are re-created?). That's not the sort of assumption I want to see go unstated in a Standards Track RFC. Better would be to avoid the ambiguity altogether. For example, OS X does not have a requirement that network interfaces have unique names. There is a UUID that identifies network services, which are related to the network interfaces the system configuration service manages, but network *services* on OS X are not the same as network *interfaces*, and they are not mapped 1:1 to one another. -- james woodyatt <[email protected]> core os networking -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
