Follow Slashdot stories on Twitter


Forgot your password?
Networking The Internet

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 popped into existence.'"
This discussion has been archived. No new comments can be posted.

The Night the IETF Shut Off IPv4

Comments Filter:
  • Okay... (Score:5, Interesting)

    by TFer_Atvar ( 857303 ) on Friday March 14, 2008 @03:28PM (#22753966) Homepage
    Who else put in their address bar just to see what would happen?
  • DHCPv6 (Score:4, Interesting)

    by tlambert ( 566799 ) on Friday March 14, 2008 @03:59PM (#22754276)
    I _really_ fail to understand the rationale for DHCPv6.

    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)

    by michaelwigle ( 822387 ) <> on Friday March 14, 2008 @04:06PM (#22754368) Homepage
    Ok, I got a server not found from work and from home so I can only assume I'm not set up right in either place. So, who can point me to what's probably wrong (for home, not work)? I'm running a NetGear router (don't remember what model) but I presume it doesn't support IPV6. Does that mean I have to replace my router in order to be able to view IPV6-only sites? How do I know if I buy a new router that it will support them?
  • by Cadre ( 11051 ) on Friday March 14, 2008 @04:13PM (#22754450) Homepage
    I did, though I expected it to work since I have had IPv6 access for awhile now. I just didn't know that Google had an IPv6 site. Google's homage to the dancing Kame is pretty nice.
  • Re:I was there (Score:5, Interesting)

    by Zarhan ( 415465 ) on Friday March 14, 2008 @04:13PM (#22754460)
    I _really_ fail to understand the rationale for DHCPv6.

    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)

    by Midnight Thunder ( 17205 ) on Friday March 14, 2008 @04:36PM (#22754656) Homepage Journal
    The trouble with ipv6 is that ipv4 works so well for 90% of the population (in the same manner that 76% of statistics are made up on the spot) that nobody who doesn't really care about this won't put in an effort to make the switch. It looks like going 100% ipv6 is quite a few years off, foo.

    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 [] 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)

    by Anonymous Coward on Friday March 14, 2008 @04:54PM (#22754800)
    Recently, I turned off IPv6 on all my FreeBSD servers. NOBODY NOTICED!

    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)

    by jd ( 1658 ) <> on Friday March 14, 2008 @05:19PM (#22754986) Homepage Journal
    I believe IPv5 is formally defined as TUBA, although another poster mentions realtime connections (which wouldn't seem to be an IP version, per se, but the layer running over IP) and POTS (which I'm damn sure is a layer 1 to layer 2 concept). There's also an IPv7. As far as I know, no TUBA drivers exist for Linux (damn shame) and I'm very certain no services (eg: DNS) exist for it.

    (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.)

  • by frieko ( 855745 ) on Friday March 14, 2008 @06:02PM (#22755292)
    IPv6 has around 10^23 addresses per square meter of Earth. The only reason I can think of that we would want to replace it would be if we found a superior replacement for the entire concept of packet switching.
  • Re:DHCPv6 (Score:3, Interesting)

    by Junta ( 36770 ) on Friday March 14, 2008 @08:53PM (#22756566)
    Others have mentioned the accounting thing, I think that's a very good example, it's much easier to track what is going on when a definitive DHCPDISCOVER transaction appears. One could make the argument for DNS update requests to be a good indicator, but that's not nearly as to the point and not required to occur.

    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).
  • by JSBiff ( 87824 ) on Friday March 14, 2008 @09:12PM (#22756664) Journal
    Well, you're right, I know the manufacturer's would love to sell you new routers. But I've often wondered why there is no market for 'premium firmware upgrades'. That is, let's say I've got a Linksys home router. The hardware is perfectly capable of handling IPv6 - if the firmware just supported it. Yes, I could upgrade to OpenWrt or some other 3rd-party firmware (I think I might, soon, because I've been having on-going issues that I think might be un-fixed bugs in the official firmware), potentially, but I don't see a lot of people ever doing that (voiding your warranty and risking 'bricking' your unit is pretty scary to most people).

    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)

    by Anonymous Coward on Friday March 14, 2008 @10:14PM (#22757028)
    DHCP for troubleshooting is relatively stupid, especially on the scale of your network. A local coffee shop? Sure. Not an enterprise. What if someone throws a rogue DHCP server on the network? The solution is to actually monitor your network. If you have thousands of switches and routers, I bet they're Cisco and I bet you can get Ciscoworks or something better to dump MAC-IP mappings for you as well as do the basic network monitoring you should be doing.

    And I don't even do network administration for a living.
  • Re:DHCPv6 (Score:2, Interesting)

    by j h woodyatt ( 13108 ) <> on Saturday March 15, 2008 @01:22PM (#22760122) Homepage Journal
    While DHCPv6 is currently the only implemented [barely] way to configure hosts with NTP, WINS, et cetera, it is absolutely NOT the best practical way to do it. A simpler and more robust way to do it would be to configure hosts only with addresses for their recursive DNS resolver proxies and let them use DNS-SD to obtain configuration for other services.

    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.

"Never face facts; if you do, you'll never get up in the morning." -- Marlo Thomas