Re: [LAD] FOSS Ethernet Soundcard

On Tue, Nov 24, 2009 at 08:35:10PM +0100, Karl Hammar wrote: 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. 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). 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: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver