The Night the IETF Shut Off IPv4

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.'"

Comments

Okay...

[TFer_Atvar]

Who else put ipv6.google.com in their address bar just to see what would happen?

DHCPv6

[tlambert]

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:I was there

[Zarhan]

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

IPv5

[jd]

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