In einer eMail vom 08.07.2008 19:25:36 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]:
Earlier, Lixia Zhang wrote: % BTW here is what I got from other msgs on this thread, % that is MAC address is not an ideal node ID in the % strict sense, as it is associated with a specific % interface, while hosts are increasingly multihomed % today. I would suggest that we distinguish carefully between: A) using a MAC address as an interface-ID [MAC] A) using a MAC address as a node-ID [MAC] B) using a MAC address as a handy set of bits to use in deriving a node-ID. [f(MAC)] % There are really two issues: % 1/ the need for a unique node ID Depending on the details of one's design, I do not think that one necessarily needs a Node-ID to be absolutely globally-unique. In the case that my design is hereby meant (otherwise ignore this email): I started out asking for approx. 2 additional octets for the sake of forwarding e.g.from Europe to California without looking at the dest. address, and only thereafter, while evaluating the dest address, to get to Sausolito.This additional information (it might be viewed or not be viewed as a Node-Id) wouldn' t have been globally unique - of course not. Later on LISP-folks admitted, that they do not consider LISP being the clean-slate solution for eternity. But since then, there has been still interest in a so-called clean-slate solution. And also: There has been the discussion about the role of IPv6 (yes, I do envy those IPv6-folks who managed to get 16 octets for the address, by which you can identify any fraction by the million of any square-millimeter of the globe.). Hence I tried to improve my design such that forwarding hops can be done by one single table-lookup even down to the last egress node ( no matter whether inter- or intra-domain) - sure, by asking for more than 2 octets. But IPv6 can easily cater for the necessary octets. I do think that it is normally helpful if a Node-ID is very likely to be unique. Again, depending on the details of one's design, I also think it is necessary for a Node-ID to be unique within the context of some given Locator. % 2/ an engineering judgment call of whether % one could borrow MAC address to serve the % above purpose. % % 2/ represents an engineering tradeoff % because the borrowing saves the trouble % of managing another new ID space. If there were a new identifier space that in no way derived from any property of the node, this would create some significant issues: - political (e.g. who manages that space ? and under what rules ?) - deployment (e.g. getting IDs into systems) - other So I think a very reasonable approach is to use some MAC that belongs to a node as input to some function that then generates a Node Identifier. One could use such a generated Node Identifier to name the node -- rather than limiting that Identifier to naming a single interface of the node. Here I am completely lost.Will say: I do not understand why MAC addresses come now into play. But I have learnt to be patient. Cheers, Heiner As it happens, IPv6 normally does something pretty reasonable here, which is to use the MAC address bits and apply a function to transform them into an EUI-64. While current IPv6 uses a different EUI-64 on each different interface, one could easily imagine an alternate design where a common EUI-64 were used to name the node (hence a common EUI-64 is used with ALL interfaces). Cheers, Ran Atkinson [EMAIL PROTECTED]
