On Tue, Nov 24, 2009 at 08:35:10PM +0100, Karl Hammar wrote: > > > uint32_t ip_addr = 192 << 24 | 168 << 16 | ethernet_addr & 0xffff; > nothing less. If you haven't listend closely enougth, this was to show > that you can do the same thing in IPv4 as in IPv6.
That's why I said "unless talking kernel level". The real difference with IPv6 is that you have plenty of addresses, so you don't have to abuse an RFC1918 network for a link local address. You just have one assigned from the kernel, that's all I've said. And when the kernel assigns and handles it, the app doesn't have to do it. Which reduces complexity. Which doesn't require an app to be able to set interface addresses (read: root permissions). Which is, to me, a good thing. YMMV. I'm happy to go away and not bother you with the progress network programming made during the last 10 years. Speaking of which: IPv4 already has this kind of link-local MAC-derived addressing: the DHCP fallback block 169.254/16, as specified in RFC3330. I know that this partially contradicts my argumentation, at least wrt to auto-assigned link-local addresses. > Somewhere you have to do the bitstuffing. And if you already > understand things like this, how would you implement the link local > address in IPv6? I don't have to, the kernel already does it. That's all I've said. The added abstraction and address range makes it so easy for the application programmer. He doesn't have to care. And since programming for IPv6 gives you IPv4 for free (dual-use sockets), coding for IPv4-only clearly isn't beneficial. Of course, you are free to code whatever you want, but I don't see why one would focus on IPv4-only when he could get IPv6+IPv4 with modern code. (think of getaddrinfo() and getnameinfo(). Two functions, no need to know more). > > struct sockaddr_storage > So that means that if you didn't work at the networking chair, > I would be free to ignore you? You are always free to ignore me. I just see so many code out there in the wild which has things like int ip_addr; inet_addr(); and the lot. Perfectly legal in the mid-90ties, but completely unportable wrt to IPv6. New code shouldn't do this anymore, hence the rude reflex. My apologies. -- mail: [email protected] http://adi.thur.de PGP/GPG: key via keyserver _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
