Forgot your password?
typodupeerror
Networking The Internet

One Less Reason to Adopt IPv6? 174

Posted by CmdrTaco
from the adopt-a-puppy-instead dept.
alphadogg writes "For a decade, IPv6 proponents have pushed this upgrade to the Internet's main communications protocol because of its three primary benefits: a gargantuan address space, end-to-end security, and easier network administration through automatic device configuration. Now it turns out that one of these IPv6 benefits — autoconfiguration — may not be such a boon for corporate network managers. A growing number of IPv6 experts say that corporations probably will skip autoconfiguration and instead stick with DHCP, which has been updated to support IPv6."
This discussion has been archived. No new comments can be posted.

One Less Reason to Adopt IPv6?

Comments Filter:
  • by morgan_greywolf (835522) on Monday September 17, 2007 @11:24AM (#20636911) Homepage Journal
    DHCP in an IPV6 world is a buggy whip [wikipedia.org]. It's not necessary. An IPV6 device can discover its own IP address and gateway router and subnet mask (if necessary) without the help of any servers because it's built into the protocol stack.

    DHCP doesn't give a network admin any more control over a network, either. That's just a silly statement. How does having a server doling out IP addresses make it any easier to control a network? It's not a like a device *must* be set to use DHCP. It's not difficult to figure out what IP address ranges a DHCP server is not doling out and use that, even on IPV4.

  • by Lxy (80823) on Monday September 17, 2007 @11:31AM (#20637025) Journal
    Autoconfig is nice for home networks and such. For the corporate world, DHCPv6 is far more useful.

    Most people think of DHCP as just giving an IP address, mask, gateway, and DNS. DHCP can do SO much more. We're talking HUNDREDS of pieces of data, including custom strings. Want to tell your IP phone where the call manager is? DHCP. Want to tell your Netware clients where the nearest replica server is? DHCP. Still using WINS for some strange reason? DHCP.

    Autoconfig is nice for the lazy admin, but for folks who want to keep track of where their IPs are going and want to deploy additional features, DHCP is the better option.
  • by Anonymous Coward on Monday September 17, 2007 @11:32AM (#20637039)

    An IPV6 device can discover its own IP address and gateway router and subnet mask (if necessary) without the help of any servers because it's built into the protocol stack.
    What about DNS and NTP servers, and domain name?
  • Re:DHCP plain sucks (Score:3, Interesting)

    by Epsillon (608775) on Monday September 17, 2007 @11:59AM (#20637473) Homepage Journal
    Thank you. I had been wondering how to get DNS to Just Work [TM] over an autoconfigured v6 interface for a while. I had been falling back to using the dhclient-enter-hooks file to stop a rewrite of resolv.conf on v4 lease acceptance and manually applying my nameservers' v6 addresses. This is the problem with any "new" technology that replaces something ubiquitous; the accepted ways of doing things sometimes no longer apply. It doesn't help that OpenBSD's dhclient dropped support for many options that I successfully used with the old ISC client in dhclient.conf. Like you, I will be glad to see the back of DHCP.

    I'll be trying it on FreeBSD and, according to the Wiki and a few other links the search "FreeBSD mDNS" returned, it looks like it is going to work. This is the final piece of the puzzle for me, apart from a suspected bug that fragments UDP NFS packets [1] when used over v6 - which is nothing to do with the v6 specification at all, just FBSD's implementation of it in either KAME or NFS.

    [1] Lots of "kernel: ipfw: pullup failed" messages on the server after a while [2] of working fine. The client hangs dead once this starts (NFS mounted /home). It might even be a problem with ipfw2. More testing needed before I start pointing fingers in a PR just in case I've screwed my configuration up in some brain-dead manner.
    [2] FSVO "a while".
  • by cwolfsheep (685385) on Monday September 17, 2007 @11:59AM (#20637479) Homepage
    I'm deploying an IPv6 VPN at my company, and I've avoided the use of DHCPv6, as they have avoided DHCPv4 to make it less easy for people to attach to our networks. By using stateless autoconfig and not having DHCPv6, I can still restrict use of company nameservers to systems with our loadsets that have the DNS setup statically defined.
  • address space (Score:5, Interesting)

    by SuperBanana (662181) on Monday September 17, 2007 @12:07PM (#20637581)

    a gargantuan address space,

    Methinks one reason IPv6 hasn't been adopted is because those who have chunks of the IPv4 space are quite happy having what is essentially an artificially precious resource.

    Most people think the IP address space is "nearly full", but a handful of companies are sitting on prime real estate (nevermind there is a huge amount of "reserved" space which is not in use.) For example, why do the following companies have entire class A's to themselves?

    • Ford
    • Prudential Securities
    • Department of Social Security of UK (WTF?)
    • Eli Lily and Company
    • Haliburton
    • Defense Information Systems Agency has FOUR, YES, FOUR, ENTIRE CLASS A's
  • premature... (Score:2, Interesting)

    by pjr.cc (760528) on Monday September 17, 2007 @12:21PM (#20637815)
    It all seems a little premature to me. Both sides have benefits and pains.

    But IPv6 (while i remember it being chosen as "the standard" we'll go with moving forward back in 1994 or 5?) is seriously at a point where IPv4 was when the internet was nothing more than a research network used by universities.

    DHCPv6 has a number of advantages for a corporation, where it exists in the network and where it doesn't will still remain the same.

    Cisco IOS's many integrations into dhcp v6 are interesting, but so much of it is way too idealistic at this point. IMHO, autoconfig will be pushed out to those routers for home networks where people dont want to know squat about their network and dhcp will probably be used in corporations for the extra functionality it gives.

    Now, claiming dhcpv6 gives you control over your network space (even given cisco's embedded features) any more than dhcpv4 did for ipv4 is perhaps a little bit of a stretch. What i would say about dhcp vs autoconfig is that dhcp allows you to pass alot more info to your clients that does autoconfig. Using it for anything more than passing info to your clients and passing out ip addresses is just asking for a management nightmare at this point in time though.
  • by TheSkyIsPurple (901118) on Monday September 17, 2007 @01:11PM (#20638815)
    >DHCP doesn't give a network admin any more control over a network, either.

    Sure it does.
    I can set certain classes of my clients to use a certain set of DNS servers; I can black list specific MAC addresses from getting an address, or I can grant them addresses on a VLAN that has no corporate access but has Internet access; I can have a central location that records the addresses of my clients and who they're linked with, etc...

    At least these are services I'm used to right now with DHCPv4. I'm going to be pissed when we make the move to IPv6 and I don't have these same features.

    To your specific argument about why it doesn't give any more control... Yes, there are trivially simple ways to get around the need for DHCP, but that doesn't mean it doesn't provide a benefit when it's there. And actually, since I have a list of folks who properly negotiated their addresses, it's not difficult to scan the network for functioning addresses and if I don't have a registration... route them to NULL. How would I accomplish that in autoconfig?

    Even without that, just being able to look at a console and say "hmm, I'm running about 80% utilization of addresses, I need to think about adjusting something here...". How would I get that sort of proactive info in autoconfig? Or is the answer the same as so much else in IPv6? (Make the individual subnets so large that it'd be impossible to fill them up)
  • by dgatwood (11270) on Monday September 17, 2007 @02:08PM (#20639889) Journal

    Yup. I hate to say it, but I was kind of hoping we'd see one nuclear silo launch and drop a nuke harmlessly into the ocean just to remind people of how f*cked we could have been.

  • by jc42 (318812) on Monday September 17, 2007 @02:45PM (#20640569) Homepage Journal
    What's up with the OSI protocols? NIH I guess. Lets all re-invent the wheel instead.

    That's not the problem that I saw, 15 or 20 years back, when I was involved in a number of OSI implementation projects. We were in fact looking at several competing protocols, with the idea of implementing them all and developing test suites to determine their good and bad points.

    But something interesting happened on all the OSI projects: We'd need the specs, of course, and you couldn't download them. You had to order the hard copy. This meant going through the usual corporate red tape for ordering stuff. You'd fill out a requirement doc, get it ok'd. You'd fill out a purchase req, figure out whose signatures you needed, and have the secretaries work on collecting the signatures. You'd mail off the order, and wait.

    Meanwhile, since there was a lot of waiting to do, we'd work on the IP version. We'd download the RFCs, spend an hour or so reading and a few hourse discussing, and then we'd sit down at a terminal and start coding. We'd be at the testing stage within a day, and have usable results in a few days. By the time the OSI specs showed up on our desks, we'd have had the IP version up and running for weeks. While we were reading the OSI specs (always much larger than the IP specs), we'd have users getting experience with the IP version, and sending in bug reports and/or change/feature requests. By the time we finally got an OSI version to the alpha stage, the IP version would be ready to send to the first customers.

    If the OSI gang had had the sense to make their docs available free on the Internet, they might not have lost so badly. But by trying to make the specs a profit center, and by using a different competing delivery network (the postal system), they put a major time blockade in the way of developers. So they lost out big time to IP.

    I've never been all that convinced that IP was any better than OSI, especially now with the big migration to IPv6 peering over the horizon. But I never really got a good chance to test them and compare their capabilities. The OSI version of our code was always so far behind the IP version that the whole issue was moot. IP won every race, because OSI was so slow out of the starting box. And that was because we developers couldn't get out hands on the specs in a timely manner.

  • by belphegore (66832) on Monday September 17, 2007 @04:52PM (#20642733) Homepage

    NAT is the solution to the address space problem. Get used to it, because ipv6 has spent the last five years failing to become a solution. When we finally run out of ipv4 addresses, we aren't going to switch to ipv6, we're going to switch to using NAT at the ISPs. You won't get an internet-routeable address for anything other than a server, after that happens - regular DSL lines will be allocated an address from one of the private ranges and NATted onto a smaller pool of routeable addresses as they leave the ISPs network.
    This is already what happens with cellular data services. When your EDGE connection comes up, you find your phone has a 10.x.y.z IP address.
  • by jd (1658) <imipak@noSPam.yahoo.com> on Monday September 17, 2007 @05:55PM (#20643711) Homepage Journal
    Anycast is not routed to the nearest device, anycasting is multicast to ALL devices by means of the anycast common address and the nearest one replies. Thus, it does indeed find the nearest device without any device at all having knowledge of where such devices are. No hardcoding is required. There is no single point of failure. If a server goes down, then that doesn't respond and the next nearest is the one that responds. Thus, with anycast, if you have an address, it is a working address. DHCP offers no such security or validation.

    No, IPv4 does not support anycast except as a userspace layer on top of multicast, which - in the case of IPv4 - is usually disabled and is not even implemented as standard on all kernels. There is no kernelspace anycasting in IPv4 and there are no anycast-aware applications in IPv4 that I am aware of. Multicast, yes, but even that is grossly underused and underutilized. Network programmers and ISPs should feel utterly ashamed with themselves at the pathetic, tardy and haphazard use of one of the most elegant networking tools available to software engineers.

    You are also incorrect about the hardcoding. Anycasting doesn't require a hardcoded address for the service. The anycast request is sent on the anycast broadcast channel and is labeled. If the device recognizes the label and no other response has been given, the device responds.

    You are also incorrect about the security risk. Multicasts (and therefore anycasts) have a scope. So long as anything outside of your local scope exceeds the anycast scope, the transmissing can never reach a device outside of the boundary you have defined.

    Let us say you have a hundred IP phones, all in factory default state. You pneous DHCP hits is going to more than inconvenience most servers. You'd damn-near melt them.

    Of course, this isn't limited to DHCP. Traditional PXE is unicast, hard-coded and doesn't scale to more than a dozen or so nodes on a LAN for truly simultaneous connections. Anycast PXE scales as far as you like, provided you have the servers to support the clients.

The bogosity meter just pegged.

Working...