6 ms·

No. An IPv6 address can be partially derived from a MAC, but a lot of the time it won't be. For instance, none of the VMs we operate (which all have an IPv6 /

No. An IPv6 address can be partially derived from a MAC, but a lot of the time it won't be. For instance, none of the VMs we operate (which all have an IPv6 /64 assigned) have real network hardware, so it makes no sense to generate the IPv6 address from a MAC there. And you can still multihome a single IPv6 address across more than one physical interface, so again, that's not somewhere you'd want to put a MAC into an IP address. > On CircleID someone recently pointed out that IPv6 will make this sort of "job" meaningless. Er... not sure how that follows. If routing tables aren't going to grow without bound, there's no less need for central allocation authorities than there is with IPv4. The important job isn't rationing, it's keeping allocation as contiguous as possible so the network hardware can keep up. > Back to your point about MAC's: This is also why the "we're out of IP addresses" meme seems silly. Because we don't see the IEEE complaining they are "running out of MAC's". And IPv6 addresses use MAC's. Not quite sure what you're getting at here. When people say "we're out of IP addresses", they're talking about IPv4 addresses. That's not silly at all - it's real, it's happening now, and IPv6 still hasn't quite got the penetration to get us out of the hole yet. The rest of your post would be more useful with some specifics.

iioowwee 14y ago
The rest of your post would be more useful with some specifics. I translate this as: "I don't know how to make a solution. Please tell me how." Which is often followed by "It won't work." As for VM's, it's true what you say. But at some point if you are connecting to a global network (internet), there is a physical machine that has to connect. And that machine needs an address which cannot be "faked up". Indeed, you some sort of authority to make sure people are not using the same addresses. Nodes need a way to find each other. Routing tables are simple enough and they work. I will leave that alone. But people have come up with all sorts of complicated schemes to try to allow nodes to find each other in a decentralized way, namely DHT type stuff and progeny of DHT type thinking. But who says you have to mess with (replace) the existing infrastructure? Maybe you can just build on top of it. Maybe the exiting infrastructure is a bootstrap. The buzzword is overlay. Old hat, right? Well, almost nothing is truly new. And still, the overlay approaches people know about are often mindlessly complicated. We can do better. Some have done better. NAT doesn't try to replace the existing framework. It just deals with it. It isn't pretty, but this is how we are all connecting, in spite of all the IPv4 policy nonsense. NAT solved a problem. (And created a new one, arguably.) Whatever. It works. There are easy ways for nodes, with crusty old IPv4 addresses, to get through their crusty old NATs and get open UDP ports to communicate with each other. They are not new. And they work. Gamers have been using stuff like this for decades. But there's a lot more utility to being directly connected than just playing games. Enter Skype. Once that's done, once we're connected directly, we can forget about overblown global routing tables, brittle BGP, DHT and IPv6 dreaming. We can use plain ole Ethernet, we can keep our own small arp and IP routing tables, we can use private address space (or whatever numbers we want - it's our private network) and MAC's. We can run our own DNS. We can keep things simple and secure. Because we can have small private networks. We can manage them ourselves. The global network was means to an end: finding each other and conecting directly. It was a bootstrap. If it runs on crusty ole IPv4 and depends on NAT and swollen routing tables, so be it. That's not my network. It is just a means to an end. Personally I never understood the lure of connecting to a "swarm" via some DHT. And this is the thinking that has pervaded peer-to-peer. The concept of connecting to strangers, something like Chatroulette, is not really interesting from my perspective. But a lot of technically capable people think that sort of thing is worth their time. I want to connect to my friends and family, not random strangers. I want to use the internet for all the things it's been cracked up to be for so long: a replacement for postal mail, telephone, video conferencing, etc. And I do not think I am alone in this view. It's not a new idea what I'm getting at: breaking things into smaller pieces to manage them. What is the internet after all but a conglomeration of ASN's -- smaller networks. "BOOTP for the global internet." A way to find each other. And then a way to connect. Opensupernodes. The rest, what you do after connecting, is up to you. That's _your_ network, not Facebook's, Google's, Microsoft/Skype's or anyone else's. Cooperation, interoperability, (at least ostensible) simplicity. People's comfort with working and playing in small groups. These are the important points in my mind.
- regularfry 14y ago
  > I translate this as: "I don't know how to make a solution. Please tell me how." That would be a mistranslation. Try "I can't tell what you're referring to, or if you know what you're talking about." We already have a solution to running out of IP space - it's called IPv6. > As for VM's, it's true what you say. But at some point if you are connecting to a global network (internet), there is a physical machine that has to connect. And that machine needs an address which cannot be "faked up". Indeed, you some sort of authority to make sure people are not using the same addresses. The IP addresses for the VMs can't be "faked up" either. They need to be publicly visible. > But people have come up with all sorts of complicated schemes to try to allow nodes to find each other in a decentralized way, namely DHT type stuff and progeny of DHT type thinking. DHT is irrelevant. > But who says you have to mess with (replace) the existing infrastructure? Maybe you can just build on top of it. Maybe the exiting infrastructure is a bootstrap. The buzzword is overlay. Old hat, right? Well, almost nothing is truly new. And still, the overlay approaches people know about are often mindlessly complicated. We can do better. Some have done better. Ok, this is where some specifics would be useful. What "better" approaches have you got in mind? > NAT doesn't try to replace the existing framework. It just deals with it. > It isn't pretty, but this is how we are all connecting, in spite of all the IPv4 policy nonsense. NAT solved a problem. (And created a new one, arguably.) Whatever. It works. Except when it doesn't. That's the point. NAT is just broken for a lot of use cases. > Once that's done, once we're connected directly, we can forget about overblown global routing tables, brittle BGP, DHT and IPv6 dreaming. We can use plain ole Ethernet, we can keep our own small arp and IP routing tables, we can use private address space (or whatever numbers we want - it's our private network) and MAC's. We can run our own DNS. We can keep things simple and secure. Because we can have small private networks. We can manage them ourselves. s/can/have to/g. Sure, you can "solve" the problem by balkanising everything. Most people would regard that as a huge step backwards, to be avoided at all costs. > The global network was means to an end: finding each other and conecting directly. It was a bootstrap. If it runs on crusty ole IPv4 and depends on NAT and swollen routing tables, so be it. That's not my network. It is just a means to an end. So you'd foist complexity on the rest of the world because your use cases don't match everyone else's? Nice. You say you want simplicity? Ethernet-over-UDP between asymmetrically NATted private networks, relying on some unspecified entity resolution protocol and UDP hole-punching, is precisely the opposite. It comes with the added bonus that you've made establishing a connection in the first place ludicrously expensive. You're arguing against a bigger, global network which supports all the use cases you're talking about and fixes the problems we're running into with IPv4, in favour of a hideously inefficient scheme which breaks things people want to do today. > I want to connect to my friends and family, not random strangers. And yet here you are, communicating with a random stranger on a random website, which is only possible right now because of a flat global public IP space.
wmf 14y ago
For instance, none of the VMs we operate (which all have an IPv6 /64 assigned) have real network hardware, so it makes no sense to generate the IPv6 address from a MAC there. But each vNIC does have a subnet-unique MAC address, right? Why not use it? And you can still multihome a single IPv6 address across more than one physical interface, so again, that's not somewhere you'd want to put a MAC into an IP address. As long as you break the tie deterministically, I don't see the harm in picking one of the interface MACs.
- regularfry 14y ago
  > But each vNIC does have a subnet-unique MAC address, right? Why not use it? Why use it at all? If it's not related to a real, physical item (and maybe you don't make any guarantees about MAC uniqueness across VM clusters), it's pointless bureaucracy. > As long as you break the tie deterministically, I don't see the harm in picking one of the interface MACs. Again, why would you bother to do this? If you've picked one of the NICs as "blessed", you're one hardware replacement (or network reconfiguration) from neither being blessed - so why not just assign in sequence from whatever netblock you're dealing with to start off with, and ignore the hardware?

iioowwee 14y ago

The rest of your post would be more useful with some specifics. I translate this as: "I don't know how to make a solution. Please tell me how." Which is often followed by "It won't work." As for VM's, it's true what you say. But at some point if you are connecting to a global network (internet), there is a physical machine that has to connect. And that machine needs an address which cannot be "faked up". Indeed, you some sort of authority to make sure people are not using the same addresses. Nodes need a way to find each other. Routing tables are simple enough and they work. I will leave that alone. But people have come up with all sorts of complicated schemes to try to allow nodes to find each other in a decentralized way, namely DHT type stuff and progeny of DHT type thinking. But who says you have to mess with (replace) the existing infrastructure? Maybe you can just build on top of it. Maybe the exiting infrastructure is a bootstrap. The buzzword is overlay. Old hat, right? Well, almost nothing is truly new. And still, the overlay approaches people know about are often mindlessly complicated. We can do better. Some have done better. NAT doesn't try to replace the existing framework. It just deals with it. It isn't pretty, but this is how we are all connecting, in spite of all the IPv4 policy nonsense. NAT solved a problem. (And created a new one, arguably.) Whatever. It works. There are easy ways for nodes, with crusty old IPv4 addresses, to get through their crusty old NATs and get open UDP ports to communicate with each other. They are not new. And they work. Gamers have been using stuff like this for decades. But there's a lot more utility to being directly connected than just playing games. Enter Skype. Once that's done, once we're connected directly, we can forget about overblown global routing tables, brittle BGP, DHT and IPv6 dreaming. We can use plain ole Ethernet, we can keep our own small arp and IP routing tables, we can use private address space (or whatever numbers we want - it's our private network) and MAC's. We can run our own DNS. We can keep things simple and secure. Because we can have small private networks. We can manage them ourselves. The global network was means to an end: finding each other and conecting directly. It was a bootstrap. If it runs on crusty ole IPv4 and depends on NAT and swollen routing tables, so be it. That's not my network. It is just a means to an end. Personally I never understood the lure of connecting to a "swarm" via some DHT. And this is the thinking that has pervaded peer-to-peer. The concept of connecting to strangers, something like Chatroulette, is not really interesting from my perspective. But a lot of technically capable people think that sort of thing is worth their time. I want to connect to my friends and family, not random strangers. I want to use the internet for all the things it's been cracked up to be for so long: a replacement for postal mail, telephone, video conferencing, etc. And I do not think I am alone in this view. It's not a new idea what I'm getting at: breaking things into smaller pieces to manage them. What is the internet after all but a conglomeration of ASN's -- smaller networks. "BOOTP for the global internet." A way to find each other. And then a way to connect. Opensupernodes. The rest, what you do after connecting, is up to you. That's _your_ network, not Facebook's, Google's, Microsoft/Skype's or anyone else's. Cooperation, interoperability, (at least ostensible) simplicity. People's comfort with working and playing in small groups. These are the important points in my mind.

regularfry 14y ago
> I translate this as: "I don't know how to make a solution. Please tell me how." That would be a mistranslation. Try "I can't tell what you're referring to, or if you know what you're talking about." We already have a solution to running out of IP space - it's called IPv6. > As for VM's, it's true what you say. But at some point if you are connecting to a global network (internet), there is a physical machine that has to connect. And that machine needs an address which cannot be "faked up". Indeed, you some sort of authority to make sure people are not using the same addresses. The IP addresses for the VMs can't be "faked up" either. They need to be publicly visible. > But people have come up with all sorts of complicated schemes to try to allow nodes to find each other in a decentralized way, namely DHT type stuff and progeny of DHT type thinking. DHT is irrelevant. > But who says you have to mess with (replace) the existing infrastructure? Maybe you can just build on top of it. Maybe the exiting infrastructure is a bootstrap. The buzzword is overlay. Old hat, right? Well, almost nothing is truly new. And still, the overlay approaches people know about are often mindlessly complicated. We can do better. Some have done better. Ok, this is where some specifics would be useful. What "better" approaches have you got in mind? > NAT doesn't try to replace the existing framework. It just deals with it. > It isn't pretty, but this is how we are all connecting, in spite of all the IPv4 policy nonsense. NAT solved a problem. (And created a new one, arguably.) Whatever. It works. Except when it doesn't. That's the point. NAT is just broken for a lot of use cases. > Once that's done, once we're connected directly, we can forget about overblown global routing tables, brittle BGP, DHT and IPv6 dreaming. We can use plain ole Ethernet, we can keep our own small arp and IP routing tables, we can use private address space (or whatever numbers we want - it's our private network) and MAC's. We can run our own DNS. We can keep things simple and secure. Because we can have small private networks. We can manage them ourselves. s/can/have to/g. Sure, you can "solve" the problem by balkanising everything. Most people would regard that as a huge step backwards, to be avoided at all costs. > The global network was means to an end: finding each other and conecting directly. It was a bootstrap. If it runs on crusty ole IPv4 and depends on NAT and swollen routing tables, so be it. That's not my network. It is just a means to an end. So you'd foist complexity on the rest of the world because your use cases don't match everyone else's? Nice. You say you want simplicity? Ethernet-over-UDP between asymmetrically NATted private networks, relying on some unspecified entity resolution protocol and UDP hole-punching, is precisely the opposite. It comes with the added bonus that you've made establishing a connection in the first place ludicrously expensive. You're arguing against a bigger, global network which supports all the use cases you're talking about and fixes the problems we're running into with IPv4, in favour of a hideously inefficient scheme which breaks things people want to do today. > I want to connect to my friends and family, not random strangers. And yet here you are, communicating with a random stranger on a random website, which is only possible right now because of a flat global public IP space.

wmf 14y ago

For instance, none of the VMs we operate (which all have an IPv6 /64 assigned) have real network hardware, so it makes no sense to generate the IPv6 address from a MAC there. But each vNIC does have a subnet-unique MAC address, right? Why not use it? And you can still multihome a single IPv6 address across more than one physical interface, so again, that's not somewhere you'd want to put a MAC into an IP address. As long as you break the tie deterministically, I don't see the harm in picking one of the interface MACs.

regularfry 14y ago
> But each vNIC does have a subnet-unique MAC address, right? Why not use it? Why use it at all? If it's not related to a real, physical item (and maybe you don't make any guarantees about MAC uniqueness across VM clusters), it's pointless bureaucracy. > As long as you break the tie deterministically, I don't see the harm in picking one of the interface MACs. Again, why would you bother to do this? If you've picked one of the NICs as "blessed", you're one hardware replacement (or network reconfiguration) from neither being blessed - so why not just assign in sequence from whatever netblock you're dealing with to start off with, and ignore the hardware?