Sorry for not explaining L2 in my original response. The tuple of <IPAddr, MACAddr> is not guaranteed to be unique either, but we're approaching crazy-town with the probabilities. This tuple fails in a way analogous to the L2 MAC addr problem. If your L3 (IP address) network is behind a proxy and is talking to a network on the other side of another proxy, you can appear to have the same IP address as another node you are talking to. This is exactly what RFC-1918 and NAT are about.
Network: [L2 Addr A1 and RFC-1918 IP address 192.168.1.10] ---- | L3 boundary / address translator with address 71.197.146.90 | ----- internet ------ |L3 boundary / address translator with address 65.4.10.2| --- [L2 Addr A1 and RFC-1918 IP address 192.168.1.10] This works because the actual conversation is between 71.197.146.90 and 65.4.10.2, but to the two servers communicating, they each believe they are 192.168.1.10 (and they are, inside their own networks) Sorry for the pedantry and for derailing the conversation, but these problems come up often enough it's worth grinding through. Is there a reason a moderately strong random GUID generator is not enough? Sorry for coming in late if that's already been discussed. Cheers, Chris Michael Wood wrote: > On 5 March 2011 07:38, Ken Wesson <kwess...@gmail.com> wrote: >> On Fri, Mar 4, 2011 at 8:07 PM, Christopher Brown <cjbrown...@gmail.com> >> wrote: >>> It will always return a MAC address, but in a virtualized environment those >>> are a fiction and under the control of the VM creator (and hence, not real >>> physical hardware). >>> >>> Since those MAC addrs are only required to be unique within the L2 domain, >>> two separate "private clouds" in the same organization, routable at L3 but >>> in separate L2, can have VMs with conflicting MAC addrs. >>> Admittedly, it's a nit to pick, but who would want to debug that? >> Define "L2 domain". > > e.g. an ethernet network. Machines that are directly connected to > each other (possibly via a bridge/hub/switch). Somewhere where "ARP" > makes sense. > > If you have something like this: > > [A]---[B]---[C] > > where "B" has two network cards and is an IP router. Then (A-B) and > (B-C) would be two separate layer 2 domains. A and C could have the > same MAC address without any confusion, because layer 2 traffic can't > get from one side of B to the other. For that you need layer 3 (e.g. > IP), where the IP packet would be removed from the ethernet frame when > received by B and then encapsulated in a new ethernet frame before > sending it on its way. A and B's left interface would have to have > different MAC addresses, as would B's right interface and C. > >> Of course, if you consider cases like this, there can *be* no >> sure-fire way to generate a node-unique number. IP addresses are right >> out, thanks to local network addresses like 192.168.1.1. There must be >> millions of machines out there that think their name is 192.168.1.1 in >> particular. :) >> >> MAC address probably gets you as close as you can get without having >> manually-assigned node IDs, or requiring every node have a domain name >> registered (yum! expensive! Verisign would love that suggestion!) :) > > Well, MAC address and IP address together would get you closer, and > probably close enough. Is 22 bytes short enough? :) > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
