The Night the IETF Shut Off IPv4 208
IP Freely writes "At this year's Internet Engineering Task Force meeting in Philadelphia, conference organizers shut off IPv4 for an hour. Surprisingly, chaos did not ensue. 'After everyone got his or her system up and running, many people started looking for IPv6-reachable web sites, reporting those over Jabber instant messaging — which posed its own challenges in the IPv6 department. I was surprised at the number of sites and wide range of content available over IPv6. Apart from — obviously — IPv6-related sites; they ranged from "the largest Gregorian music collection in Internet" to "hardcore torrents." Virtually none of the better known web destinations were reachable over IPv6. That changed when ipv6.google.com popped into existence.'"
Okay... (Score:5, Interesting)
DHCPv6 (Score:4, Interesting)
IPv6 was designed o that stateless autoconfig resulted in routable addresses.
Combine that with ZEROCONF, and you can discover everything that a DCHP server is going to be able to tell you, and more.
The only technical rationale I've ever heard is for reverse DNS, to prevent someone getting on the local net without authorization and relaying through your SMTP server, but that requires that you configure your DHCP server to only serve to "trusted" MAC addresses. It's also totally useless with DNSUPDAT, since anyone who gets an address can update the reverse in their home domain, and relay out that instead (which is more secure anyway).
So the only rationale I see is controlling access to network dialtone (a business rationale, based on the business model of selling packets rather than selling pipes - a model I happen to disagree with allowing to continue to exist).
So whose idea was it to turn on DHCPv6?
-- Terry
Re:Okay... (Score:2, Interesting)
Homage to Dancing Kame (Score:3, Interesting)
Re:I was there (Score:5, Interesting)
IPv6 was designed o that stateless autoconfig resulted in routable addresses.
Informing client about DNS, NTP etc servers is just icing on cake.
The primary purpose is accounting (And insert whatever Orwellianisms you want here). Especially in enterprise networks. ISPs also are interested, to provide equivalent functionality to DHCPv4 "option 82" or similar ones that tie specific IP to specific user or at least DSL connection. So basically the driver is requirement to have managed IPv6 addressing without random hosts just deciding whatever they want to use (EUI-64, CGAs, whatever). In fact, the recent trend seems to be that when deploying network, DHCPv6 is not only preferred option, it seems to become the *only* allowed option. (Basically: Filter traffic so that only the DHCPv6-allocated address is allowed to communicate.)
Re:yo (Score:3, Interesting)
To you average user there should be no effort, since it should just work. The problem is that there are still gaping holes that need to be resolved. For example no DHCPv6 client provided standard with MacOS X. Sure you can get wide-dhcpv6 [sourceforge.net] and install it on your computer, but this considered to be in the realm of the experimenters.
We will get to the point where IPv6 is ready, but as the parent says most people aren't ready. You average Joe won't know that anything changed unless things break. Apple, Microsoft and Cisco still don't have IPv6 ready networks and the only people who do are just doing it for fun or out of curiosity.
that's nothing! (Score:1, Interesting)
Everything continued to work much like it did before, except the kernels were slightly smaller, and the output of certain commands was less confusing.
Amazing, eh?
Actually, I've been doing this for years. I'm not going to even think about IPv6 until popular sites are completely, 100%, inaccessible from IPv4. Because until then, I know IPv4 will work just fine. I suspect anyone else who has half a brain is doing the same thing.
But hey, whatever the IETF folks do for fun at their par-tays is their business.
IPv5 (Score:5, Interesting)
(When it comes to Linux support for protocols, it's a popular platform for early developers, but maintenance can be an issue. enSKIP and SGI's STP code are abandonware, the real-time network driver for RTAI is infrequently updated, and the GAMMA Active Messages driver is seriously stalled in a number of areas. Many updates to Web100 have just been kernel increment updates, not bugfixes or added features. I don't recall seeing any support for VIA - which is fair enough, given it's dead - or iWarp. Linux' QoS supports RED, but neglected BLUE, GREEN, BLACK, WHITE and PURPLE the last time I looked.)
Re:So,when will we have the night they shut off IP (Score:2, Interesting)
Re:DHCPv6 (Score:3, Interesting)
On a more purely technical note, how do I tell server176 boot firmware that it should be loading file 'deployimg.176', while telling server12 to be loading 'recordimg.5', or whatever? How do I tell one set of servers in a network to tftp from one server, while others in the same network to tftp from a different one? The problem with zeroconf/multicast dns as the answer to everything is that assumes quite a homogeneous network that is symmetric, and many many useful examples exist that would not be accommodated without something like DHCP that centrally deals with it. Could it be possible to make multicast dns solutions that are torturously convoluted to provide the flexibility, sure, but what did you gain from simply moving the problem from sets of established codebases to a different set of codebases?
But ultimately, the question is, what's the harm of DHCPv6? I don't see multicast DNS+routing advertisement daemons as *really* any less infrastructure to set up. An administrator simply *has* to make the basic data available one way or another. People down on DHCPv6 haven't convinced me why setting up radvd and the other stuff is really better than DHCP. DHCP only was a pain when you chose to micromange (which is merely optional, can opt not to do it if radvd would have been enough), and when having to deal with frustratingly small pool allocations (inherently rendered a moot point by the IPv6 address space).
New router. . . or maybe just new firmware (Score:3, Interesting)
Now, if I were Cisco/Linksys (I think Cisco bought Linksys awhile back, no?), I *think* I'd rather sell people a $15 firmware update which gives them cool new features, and which requires me to manufacture 0 new hardware (so the marginal profit is *extremely high*), than to sell them a $40-$60 piece of hardware which requires me to also pay for manufacturing, shipping, and give the retail outlets who are selling it a fat margin (so that, I bet, Cisco only gets $20-30 anyhow, with the rest going to Best Buy, Circuit City, Fry's, TigerDirect, etc).
But, maybe there's more margin in hardware than I realize. Granted, they have to sell hardware anyhow (e.g. for new users who don't have their hardware to begin with), but why not sell existing customers the new firmware without requiring new hardware? I suppose it comes down to there is no established precedent for people paying for firmware. . . they expect it to be free, so the market might not, at least initially, embrace buying firmware upgrades. There are also the technical support issues of having to deal with routers that got bricked because the power went out while the upgrade was in progress or something. But if the router was designed well to begin with, it should be fairly resistant to bricking during the upgrade process.
Still. . . with a marginal cost close to 0 for the 'product', and fewer other people in the chain to split the profits with (they might have to still pay some per-unit fees, like licenses if they use a proprietary 3rd-party embedded OS), it would seem like this could be a reasonably lucrative business model.
Re:DHCPv6 (Score:1, Interesting)
And I don't even do network administration for a living.
Re:DHCPv6 (Score:2, Interesting)
Just about everything on the Internet needs DNS. Application interfaces for resolving DNS and DNS-SD are well-defined. If a client application needs to discover the network location of an appropriate server, then it's easier to just go straight to the DNS for it. It's really fricking DUMB that the DHCP client needs to know what services that applications on the host might need to locate at the time of joining the network, which is potentially well before the user of the host decides to run the client. This makes DHCP clients have to ask for every last possible configuration parameter the host is even capable of using, whether it ever uses it or not, and if it doesn't ask for it, then the client application has to fail. This is TOO STUPID for words.
Oh, and your example about the web server changing its MAC address is bogus. All DHCP does is move the place where the new MAC address has to be recorded from the DNS service to the DHCP service. The real solution to that problem is to manually configure the interface address on your web server and record it in the DNS where it never has to be changed again.