Slashdot Mirror
One Less Reason to Adopt IPv6?
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."
Yeah sometimes cool features don't evolve into benefits. News? Not really.
Duh? Seriously....
If sharing a song makes you a pirate, what do I have to share to be a ninja?
But puppies don't have a "gargantuan address space" or end-to-end security. Trust me, puppies leak all the time.
I don't have a microwave. I do, however, have a clock that occasionally cooks shit.
DHCP in an IPV6 world is a buggy whip. 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.
My blog
It really does. I sometimes see people considering dhcp with ipv6 just to propagate name server settings. But IPv6+mDNS (part of zeroconf) works much better for that too, at least for apple and linux (haven't tried windows, no doubt microsoft screws it up somehow).
Subnets... which may also be a thing of buggy whip ilk.
The game.
I mentioned this when IPv6 was being touted as a good idea, years back. What's up with the OSI protocols? NIH I guess. Lets all re-invent the wheel instead.
And look, nobody wants the new wheel anyway.
Meh. Get of my lawn. Go on, the lot of you.
Deleted
IPv6 Autoconfiguration is close but no cigar in a couple of signignificant ways:
/64 addresses for hosts, the address size gain, while large, isn't anywhere near the original promise, and encoding the MAC address into a globally-visable IP address does release information about hosts which was formerly private (NIC vendor, for one, as well as the more theoretical complaint about the layering violation).
1) DNS server information wasn't baked in from the beginning (there are now some drafts to fix this, but I haven't yet seen the working code) - all this time, and we managed to recreate BootP...
2) Because autoconfiguration uses
3) Just try it with VMWare or other virtualization software. Ouch. There's a whole lot of borked there.
4) Obviously you wouldn't want to use it for a true server, becuase who wants their server IP to change when a NIC burns out?
All that said, in a dual-stack environment it works reasonably well: but it doesn't honestly look like anyone gave much thought to a time when IPv4 wouldn't be present on the LAN or on the hosts...
Need Geek Rock? Try The Franchise!
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.
There is no reasonable defense against an idiot with an agenda
:wq
There have been a number of suggestions to solve it that problem, of course, ranging from adding an extra field for DNS servers in the autoconfig ICMP messages to using well-known unicast addresses for the closest recursive DNS server to using a dedicated protocol just to discover DNS servers. The first and last of those have (rightfully, IMNSHO) been shot down because then one might "just as well" use DHCP, which exists and has a solution ready for the issue at hand. I cannot remember why the unicast suggestions have been rejected, though, and it has been disturbing me, because I think it is the best solution. I really just cannot see the drawbacks to it. I guess there might have been some talk about lack of security in that model, but that's a problem with DNS in general, though. That's why DNSSEC was invented.
Last I looked, the consensus seems to be to use autoconfig for address generation, and then request network information (such as DNS servers) from a link-local DHCPv6 server. When everything comes around, I think that's a rather good solution. Clients can still get whatever non-occupied address they want (which means the privacy extensions will also continue to work), and still get the information they find relevant, and a DHCPv6 server should be easy to implement on a network of any scale.
Well, it may be that these three reasons have always been given. But where I sit, I've only heard over and over about one reason -- address space. When stories hit the headilnes, they all say the same thing: that in X years (for some very small number X) we'll be out of IPv4 address space.
If that's true, then we don't need two other reasons (or even one other reason) to move on to v6. (Yes, we could insist on looking for some other solution to the address space problem... but is there a reason?)
So from my perspective, this story introduces two lesser reasons for the move and dismisses one of them. That sounds like a net increase of one reason to adopt in my book.
I don't think many people would expect a professionally managed corporate network to rely on autoconfiguration alone when DHCP grants a lot more flexibility. It's still a boon to home users and the less technically able.
Autoconfig is a nice default for something that "just works" without much need for an admin to plan out the network, and DHCP is great for tighter control where needed. What's wrong with having both options available?
we MUST go to IPV6! I own $10k in Cisco stock that needs to go to $20k before I break even.
init 11 - for when you need that edge.
I can currently have a machine called "arthur" that I can ping with
$ ping arthur
etc. Now, how, after autoconfiguration, do I get my machine's name "arthur" registered as belonging to this new, autoconfigured IPv6 address?
IPv6 isn't that good because DHCP has been updated to support IPv6?
O.O *blink blink* O.O
I read that as *bling bling* and wondered why a rap star between two topless chicks cared anything about IPv6.
IPv6 may offer a range of new features over IPv4, but realistically, people will move to IPv6 for one of two reasons
1. They have run out of IP addresses ( remember the 10.0.0.0 private network is pretty big! )
2. Everyone else is doing it.
Option 1 is only really going to be a problem for the really big firms, and they will be really careful. All those Corporate apps need retesting with the new IP addresses, and that is a non trivial exercise ( think Y2K all over again!, except you could do it piecemeal ). It's a hard sell to the business : Mr PHB, we'd like to spend a large amount of money retesting all the applications in Globocorp to use a new IP numbering scheme. Nope, you won't get any business benefit.
ISPs may force people of IPv6 at some point, but that's only been an issue in South Korea so far. Everyone else still has enough IP addresses right now.
And until we get a critical mass of people going for Option 1, option 2 is a no go.
IPv6 33% Pointless
One Less Reason to Adopt IPv6
IPv6 Address Assignment Choices
Some May Forgo IPv6 Autoconf. for DHCP
IPv6 Autoconf. Vs DHCPv6
NetworkWorld chic: Well, I like "33% Pointless" the best, but my editor struck it down. The informative ones are too boring. I'll get more page views with "One Less Reason..."
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.
Life is irony, and nothing ever goes as planned.
Isn't the headline and summary putting this entirely backwards? Now that DHCPv6 is available IN ADDITION to auto configuration, that's one MORE reason to adopt IPv6, or rather, on less reason to stick with IPv4. It's not like auto configuration suddenly can't or doesn't work now that DHCP is available as an alternative option.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Look, if we don't switch to IPv6 one of these days, then in 100 years from now an angry IT network sys admin is going to go insane with the mess we left him and invent a time machine and come back to blow us all up.
It is going to have to happen and the longer we put it off the more expensive it is going to get over time to replace all the equipment. Yes, NAT works but its like trying to keep an old system road infrastructure in place that will be more costly to maintain at a certain point than to replace.
"I am the king of the Romans, and am superior to rules of grammar!"
-Sigismund, Holy Roman Emperor (1368-1437)
Speaking of features that have turned into benefits, all the toilets in my house have excellent toilet seats, but now that I am moving I have no use for them. Hence, I have toilet seats for sale, any takers? I'll start the bidding at $10, its likely there is some petrified fecal matter lodged underneath, but nothing that a soak in the washing up bowl won't clean off!
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?
Please help metamoderate.
I always thought with that big of an address space they could force everybody to have their own unique biometric hash and gps coordinates encoded in the ip address.
If it's always X? Isn't it going to be a bit difficult to find the name/IP concordance if I have to add it in to every DNS system I connect to (or have to route to my DNS server all the time)?
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.
I've started my open DHCPv6 implementation over 4 years ago. Once in a while, someone reports a bug or says that it works fine, so people are using it. The rate of adoption is not that great, but I've got feedback from 28 countries. Anyway, that's hardy a news. Basic DHCPv6 spec has been published in 2003. By the way: there's a small misunderstanding. Formally, the whole autoconf process in IPv6 is split into stateless and stateful (DHCPv6) parts.
DHCP (and bootp and RARP before it) served primarily the purpose of letting an otherwise unconfigured node discover which IPv4 address it should use. Along with that, DHCP could deliver more information important to the node as well - default router, DNS information and so on.
With IPv6, the basic networking information is automatically configured when a node connects to the network. DHCP's purpose in such environments is to allow unconfigured nodes, once they've configured IPv6, to discover things like DNS servers and the like.
Personally, I thought a better idea for DNS would be anycasting - a designated site-local address could be set aside for DNS servers. With such a setup, your average *nix box could operate without a resolv.conf (or equiv) file at all. And, of course, once you have DNS set up, you could use CNAME or SRV records for just about anything else. But RFC 3879 has deprecated them, so none of that.
I see a lot of comments about DHCP being used for passing more information about services like DNS, TFTP, etc.
But DHCP is actually quite limited in the number of services that can be passed to the host and is really there for giving a IP address to a host.
Instead we could use multicast-DNS, like Bonjour for Apple. A host just request a service (including mail servers, outside DNS server, web servers, kitchen zinc server) using a multicast DNS query. This is also a better theoretical separation of layers.
In a year or two, three, you're not going to have much choice. The IANA pool of unallocated addresses is declining very rapidly.
Imperfect though it might be, IPv6 is the future...
On an IPV4 network, DHCP is quite handy even for true servers, because it gives you single point-of-control of MACIPhostname mapping. When you have to move a machine from one subnet to another, it means that you can take the machine down, update your DNS/DHCP tables, and restart the machine on the new subnet. You don't have to update anything on the machine, itself. Autoconfig doesn't do that.
I've looked a little at DDNS with DHCP, and from what I've been able to tell, the trust model appears to be reversed. It appears organized to ask if the client trusts the server, not if the server trusts the client. Perhaps from a peoples' rights point of view that's correct, but not from a network management point of view. Of course I only skimmed the documentation, and that was quite a while ago, because for my sized network the static DHCP/DNS tables have worked just fine.
Can someone summarize how DDNS names get propagated in IPV6, and how you know you can trust them?
The living have better things to do than to continue hating the dead.
Because people learned the WRONG lesson from y2k.
Nothing happened.
So the accepted wisdom became that the whole thing was just an alarmist fiasco that chewed up a bunch of money unnecessarily. They don't realize that y2k was no problem precisely because of all the noise. A LOT of people did a lot of planning and a lot of work, and that all paid off in how few problems there really were.
But the common man, and unfortunately the common leaders don't understand that. So now y2k was a so-called crisis, wasn't a problem, and we can approach our next so-called crisis without the extensive preparation we "wasted" on y2k. Oh boy!
The living have better things to do than to continue hating the dead.
"The important point to remember, though is *2 YEARS*. That's how long we have until the IPv4 address space is fully allocated at the top level."
Yes, and it's been 2 more years for quite some time.
So there are huge swaths of IP space tied up in entities which don't need any where near as many as before NAT. If ARIN's requirements for usage were enforced then we may be fine for the next 10 years. Anyone with a Class A needs to figure out what they're doing and return some major swaths of IP space:
1.0.0.0/8 - IANA
2.0.0.0/8 - IANA
3.0.0.0/8 - GE
4.0.0.0/8 - Level 3
5.0.0.0/8 - IANA
6.0.0.0/8 - DoD
7.0.0.0/8 - DoD
8.0.0.0/8 - Level 3
9.0.0.0/8 - IBM
10.0.0./8 - NAT (we all love it)
11.0.0.0/8 - DoD
Come on people - if you're going to force usage on us, then force them on all http://www.arin.net/policy/nrpm.html#four33
Now as an ISP, I want to be multi-homed, but the only "legit" mannor to do this is via an IP allocation from ARIN, otherwise you'll be forcing a renumber on your clients (not a happy thing).
(And here I was hoping to post, "Reasonable limits aren't.")
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
I'm not sure if autoconf and IPv6 addresses in general have too much or too little magic. Admittedly, these are in part Linux implementation bugs, but the kitchen sink nature of v6 sure isn't helping. If I can't reach anything by v6, I don't really care that I can secure my connection to nowhere with crypto.
On the too much magic side, I announced 5001::/64 on my LAN at home as a test. Yet, when I try to go to a v6 enabled site, firefox tries to use v6 even though 5001::0/64 in no way impleis that I can reach 2001:: from here.
On the too little magic side, some sites have more than one router (It's called a private network, some people don't care to splatter their private business all over the world). I tried setting that up with both overlapping and non-overlapping prefixes. Neither worked at all. The machines bounced from one to another so that they didn't even keep a consistant address. Good thing I had v4 so I could fix it without hopping from machine to machine. Possible good behaviours might have been:
The success or failure of v6 will be in client support. Nobody is going to accept a v6 only web server if clients can't reach it. Many of those clients have v4 only ISPs with dynamic IPs. They will not want their entire lan to renumber every time they get a new dynamic assignment. So, they will want a non-routable prefix for local to local traffic. Too bad the silly machines will try to use that for non-local traffic!
Admins are often busy people. They don't want to devote their professional life to a v6 rollout, especially when practically nothing out there is reachable by v6 yet. If it's not dead simple it won't happen at all. I tried dead simple and as a result some sites became unreachable. I killed it again and they came back (falling back to their v4 addresses).
Link local addresses don't seem to work AT ALL. I see the route but I get EINVAL if I try to ping.
I suppose my next attempt will be to rip all the autoconfig stuff out of the kernel and implement a userspace daemon. It doesn't really belong in the kernel anyway. That's what initramfs is for.
In general, this business of having to add one of 6, -6, -A inet6 or other junk to the command line or appending a 6 to the name of the utility has got to go. It's one thing to need a software update to handle v6, I can understand that older software might not even know v6 exists, but the v6 version has no excuse for not knowing v4 exists. ping6 192.168.2.1: unknown host.
All of this tells me that v6 still has the status of a toy to play around with, not a supported standard ready for worldwide use. That's fine as far as it goes, but it's not exactly making people anxious to get on with the upgrade.
It's been over a decade now. Let's quit pretending it's just inertia and try to address the real adoption barriers while there are still v4 addresses left.
My advice:
Just forget about scope. Prefix lengths are more than adequate for making routing decisions.
Quit appending a 6 to everything (this is not marketing!). That includes structs and function calls in the library. For the most part, a v6 address as ASCII is distinguishable from v4. Likewise, in binary 4 octets followed by nulls or nulls followed by 4 octets is a v4 address. An app that won't run when the size of sockaddr_in changes was wrong to begin with. If you must, make -DV4ONLY use the old v4 only structs etc so broken source will compile and run. Done right, a number of old but well written programs could support v6 just by recompiling.
Allow multiple router announcements and behave gracefully. Use the prefix that best matches the destination.
Simpler handling of 6to4 and 4to6 translations. With so many people using APs and other routers for a broadband connection now, automatic en/de-capsulation in IPv4 can go a long way with very little configuration and a few simple rules.
I'd be reluctant to go without IPv6 autoconfig. I run a DHCP server for IPv4 and enabling IPv6 wouldn't be too much hassle, but it's a great deal nicer not to have to. Arguments re shifting addresses are bogus, since you'll usually allocate addresses for services/network entities when you wish them to remain persistent anyway, just like you currently reserve static IPs in DHCP for servers.
I'm not too happy that no agreement has been reached on anycast DNS, though. The lack of a mechanism for clients to discover basic network services like DNS is a big hinderance.
Overall, though, I love the fact that I can plug my laptop in on any network and it'll either use native IPv6 (on enabled networks) or local 6to4 to get to any of my other v6 enabled hosts transparently. The old ssh proxy-command trick was bearable for punching through NAT, but v6 is so much nicer (and good for a great deal more than SSH of course).
Of course they'll skip "stateless autoconfiguration." Even if it could be upgraded to provide enough information to the client (such as the location of the DNS servers) the fact remains the the autoconfigured IP address is selected by running a reversable algorithm on the MAC address. This means that in every communication you're advertising to the entire network:
1. What manufacturer made your NIC chipset
2. With high probability which NIC chipset is in use
3. With high probability which firmware revision is installed
Add OS fingerprinting to the equation and now you're also advertising with high probability exactly which low level network driver is running on your machine.
Its a security nightmare.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Because M$ does not currently support DHCP static lease address assignment in their IPv6 implementation. Many large enterprises like to have their primary servers at a certain known address, e.g. "10.1.2.3" for proxy "10.1.2.5" fopr file server, etc. Sorry no can do in a windoze IPv6 environment. MS isn't the only culprit. Don't get me started on the debacle they called "site-local". Every place says its deprecated but precious few will inform you what to use as a replacement and best practice of that use.
Much as I would like to use it, I am afraid that until a DHCP IPv6 environment does everything (correctly) a DHCPv4 environment does on both the client and server side, it wont make much headway outside trivial or lab environments.
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
>> 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.
>
> IPv6 Anycast returns the nearest server that supports the capability you want.
Apples to oranges.
If a device has a hardcoded destination IP address (or DNS name for that matter, as it can be easily converted to IP address), Anycast will route the traffic to the nearest node with that address. That does _not_ help finding a service in the first place. You need to somehow hardcode such information in the device. This is where DHCP comes useful, as it provides autoconfiguration capabilities.
If you imagine that you have multitude of IP phones (all in factory default state) to install... with DHCP you just plug them in, they will learn correct settings from DHCP. You will not achieve the same effect with IPv6 Anycast. It would only be useful if all network users in the world have used the same IP address for their service and manufacturers have hardcoded it as factory default. Of course this brings another risk - if you mess your addressing, your IP phone (or other device) will happily connect to ANY OTHER server with the same address. security risk. IMVHO anycast is not a solution to the problem.
BTW: Anycast isn't anything new in IPv6, it's been used in IPv4 for years.
You do realize that IANA is the Internet Assigned Numbers Authority and not some bozo org getting huge swaths of unnecessary IP space? ARIN is actually subordinate to IANA.
The reason no one wants to adopt IPv6 is the fact it's the unstable testing branch. It's when IPv7 is finally released that everyone will start adopting as it will include 128 bit address spaces, privacy, big brother extensions, auto-nuke capabilities, warp drive and subspace tunneling. The next improvement will be in IPv9, when it goes to 256 bit address spaces and 11 goes to 512bit and the last IPv protocol will be 13 because that's called Borg where "Resistance is futile. You will be assimulated"..
Mod me up/Mod me down: I wont frown as I've no crown
That's exactly what I was thinking, but I didn't know for sure whether or not IPv6 had some crazy native support for this.
ARIN and RIPE's current policy is to only give new blocks to those who demonstrate they need them.
However, the policy does not include reverting old huge allocations such as those because they're only sparsely used.
Some address blocks were recovered in the past, but that was a more or less voluntary process.
The remaining wasteful allocations are not easy to recover because, despite being sparsely used, recovery involves renumbering extensive networks and the owners are not going to give them up without a fight.
Essencially, it all leads to the same point: in the near future, having a globaly routable IPv4 address is going to become a more expensive privilege.
Skype essentially solved this with a UDP hack.
But, I really, really hope this doesn't happen -- even though it already is.
Don't thank God, thank a doctor!
and they want their operating systems back
Stateless autoconfig wasn't intended to replace DHCP; it was intended for creating ad hoc IP networks without requiring additional expense and/or specialized knowledge. Some networks don't need DNS, nor even have a router (think crossover cable, or ad hoc 802.11). These networks might be created by a couple of kids who just want to play Doom together, or by executives who just want to share directions to a golf course; they don't want or need to know about the lower layers. Stateless autoconfig is a good thing as-is; people should stop thinking of it as a replacement for DHCP or vice-versa. Expand your mental toolbox, and use the right tool for the job.
those who are very vocal are not using IPv6 daily. they are from ivoly towers.
itojun
# ipv6samurais.com: Saving the World with Code and Sword
What it comes down to is philosophy. It's that simple. It's autoconfiguration's socialism (turned communism?): "From each according to their ability, to each according to their need." - Karl Marx "...all will govern in turn and soon will be accustomed to no one governing." - Vladimir Lenin Autoconfiguration is the embodiment of these ideals. Routers have an ability which hosts need. No one says what different services different clients receive (or are told to ignore). The network management is from the bottom up - from the end-clients. No one governs. This, versus DHCP fascism: "All within the state, nothing outside the state, nothing against the state." - Bennito Mussolini Again, the embodiment of DHCP (4 or 6). The DHCP server is the state, and relays, clients, all of them must succumb to the will of the operator expressed through it. Now we may debate for years - centuries - perhaps to the end of time - about which of these philosophies (if any of them!) should be applied to social governance. But I submit that if you are running a network, and you plan to make money doing so, that you probably want to exert some fascism - to be your network's fascist dictator. You probably do not want to even risk the potential chaos if just one autoconfiguration client goes off the deep end and starts making trouble for others.
It is not very surprising that some networks need a lot
of configuration information and/or tight control of what
devices are in the network.
This is why IPv6 has both a bare bones stateless mechanism
and a stateful, rich mechanism. How did this fact get turned
into "one less reason"?
FWIW, the bare bones mechanism seems to be sufficient for
a surprisingly large number of situations. I have it at
home and at the company, for instance. In a dual-stack
environment it is enough to get one set of DNS addresses
from the IPv4 side because you will in any case be able
to get the IPv6 information from the same server. SIP
phones can talk to each other using IPv6 even if they
employ an IPv4-only proxy. Etc.
The reality is that we are stuck for some parts of
our networking being IPv4-only for a long time. But
that's fine -- its OK to use IPv6 for the things you
can. For instance, I can address the IPv6 capable
devices in my home network individually from anywhere
in the world; for IPv4 I have to build complicated
sets of port and address mapping rules or SSH tunnels.
Jari