Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

One Less Reason to Adopt IPv6?

CmdrTaco posted more than 6 years ago | from the adopt-a-puppy-instead dept.

Networking 174

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

cancel ×

174 comments

Sorry! There are no comments related to the filter you selected.

Whatever Works (0, Insightful)

Anonymous Coward | more than 6 years ago | (#20636875)

Yeah sometimes cool features don't evolve into benefits. News? Not really.

Re:Whatever Works (4, Insightful)

ajs (35943) | more than 6 years ago | (#20637171)

Yeah sometimes cool features don't evolve into benefits. News? Not really.
What's news is that we're still dragging our heels on IPv6. We dodged the bullet once by developing and widely deploying NAT and at the same time reclaiming large amounts of unused address space via switching core routing to CIDR. However, that trick only bought us a certain amount of time. As the world becomes increasingly connected, we're going to face the same problem again. Why are we waiting until it's a crisis to deal with it?

Re:Whatever Works (4, Insightful)

ameline (771895) | more than 6 years ago | (#20637785)

> Why are we waiting until it's a crisis to deal with it?

Because that's just human nature -- we're all procrastinators -- some of us admit it -- others are putting that admission off.

History is replete with situations where timely action would have saved piles of money and/or lives -- have we ever acted at the right time? No -- we wait until something like http://www.historyplace.com/worldwar2/timeline/dday.htm [historyplace.com] is necessary.

So I think we can all safely predict that it will be a crisis before we do anything about it.

And remember -- never put off until tomorrow that which can be put off until the day after. :-)

Re:Whatever Works (0)

Anonymous Coward | more than 6 years ago | (#20637803)

"Why are we waiting until it's a crisis to deal with it?"

Because, by-and-large, that's how we humans operate.

Re:Whatever Works (1)

the_womble (580291) | more than 6 years ago | (#20638179)

Why are we waiting until it's a crisis to deal with it?

Because that what we always do.

Re:Whatever Works (3, Insightful)

el americano (799629) | more than 6 years ago | (#20638587)

Why are we waiting until it's a crisis to deal with it?

Because until it's a crisis, you can't get the money to upgrade. If current addressing is going to work for another week, then it costs nothing to stick with it. Call me when the crisis is imminent.

Re:Whatever Works (1)

olliec420 (1023207) | more than 6 years ago | (#20638609)

>Why are we waiting until it's a crisis to deal with it? Because thats how IT depts deal with things. Well in mine anyway.

Crisis, what crisis? (4, Insightful)

dpilot (134227) | more than 6 years ago | (#20638921)

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!

Re:Crisis, what crisis? (4, Interesting)

dgatwood (11270) | more than 6 years ago | (#20639889)

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.

Toilet Seats for Sale! Toilet Seats for Sale! (0)

Anonymous Coward | more than 6 years ago | (#20637545)

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!

Um,... it has to be said. (1)

Aranykai (1053846) | more than 6 years ago | (#20636881)

Duh? Seriously....

But... (5, Funny)

gzerphey (1006177) | more than 6 years ago | (#20636899)

from the adopt-a-puppy-instead dept


But puppies don't have a "gargantuan address space" or end-to-end security. Trust me, puppies leak all the time.

Re: But... (1)

arootbeer (808234) | more than 6 years ago | (#20639543)

But you'll note that the leak is always at one end or the other...

Re: But... (5, Funny)

Bogtha (906264) | more than 6 years ago | (#20639843)

Not to mention the fact that sniffing is a constant problem.

DHCP in an IPV6 world (5, Interesting)

morgan_greywolf (835522) | more than 6 years ago | (#20636911)

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.

In a word... (1)

thatskinnyguy (1129515) | more than 6 years ago | (#20636977)

Subnets... which may also be a thing of buggy whip ilk.

Re:DHCP in an IPV6 world (1, Interesting)

Anonymous Coward | more than 6 years ago | (#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 in an IPV6 world (3, Informative)

walt-sjc (145127) | more than 6 years ago | (#20638311)

Bah! Who needs DNS when you can just use IPv6 addresses like: http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]/

Re:DHCP in an IPV6 world (1)

nschubach (922175) | more than 6 years ago | (#20640103)

"The requested URL could not be retrieved

The following error was encountered:

The request you sent does not comply to the HTTP spec."

Re:DHCP in an IPV6 world (5, Insightful)

igjeff (15314) | more than 6 years ago | (#20637049)

DHCP does a whole lot more than that.

The reality of the situation is that stateless autoconfig in IPv6 is one way to get basic networking connectivity setup, DHCP is another. Depending on your situation, the phase of the moon, and any of a number of philosophical viewpoints held by the network admin, stateless autoconfig might or might not get used. *shrug* Even with stateless autoconfig, DHCPv6 might also get used to configure other information that is not handled by stateless autoconfig (DNS servers, NTP servers, any of a huge list of other things).

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. It may take a little longer (months?) before people start really feeling any pain from that at the end-user level. But its the critically important point for people to realize. Can you be ready for IPv6 in 2 years? You need to be. If its gonna take you 2 years to get IPv6 functioning in your network, then you need to start *NOW*.

Or have I got this wrong (4, Insightful)

Silver Sloth (770927) | more than 6 years ago | (#20637173)

If its gonna take you 2 years to get IPv6 functioning in your network, then you need to start *NOW*.
or have I got two years to configure the gateway between the corporate network and the internet? That's a much smaller task.

Re:Or have I got this wrong (1)

igjeff (15314) | more than 6 years ago | (#20638459)

Yes, that's a smaller task (though I wouldn't call it small...there are all sorts of corner cases to consider with that sort of solution).

But its the same answer. If its gonna take you 2 years, you need to start now. If its gonna take less than 2 years, then you've got a little bit of time...but do you really want to risk painting yourself in a corner if it doesn't go as smoothly as you expect?

I would say start now (if you haven't already) and if you get done before hand...well, good for you, you're ready to go early. I'd much rather be ready to go early than late.

Re:Or have I got this wrong (2, Insightful)

walt-sjc (145127) | more than 6 years ago | (#20638481)

But what about the application protocols? That's what matters. We are not just talking "gateway", but a full-blown proxy that translates IPv4 / IPv6 sessions / protocols. Then there is encryption that is built-in to IPv6 which makes this MUCH more difficult.

IMHO, this "much smaller task" isn't quite so small anymore. In fact, it's massive.

IPv6 enabled machines talking to "legacy" IPv4 applications / services is a TRIVIAL task compared to the other way around.

Re:DHCP in an IPV6 world (1)

HexaByte (817350) | more than 6 years ago | (#20637535)

"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. It may take a little longer (months?) before people start really feeling any pain from that at the end-user level. But its the critically important point for people to realize. Can you be ready for IPv6 in 2 years? You need to be. If its gonna take you 2 years to get IPv6 functioning in your network, then you need to start *NOW*.

Well, a lot of governments are going to IP6, which means their IP4 addresses will no longer be needed. As others move to IP6, their addresses can also be released back into the pool. It may be that in 3 or 4 years, only home users and small businesses are on IP4.

Re:DHCP in an IPV6 world (1)

cdombroski (1075539) | more than 6 years ago | (#20637839)

Only if the governments and large corporations don't feel like talking to the small businesses and residences...

Re:DHCP in an IPV6 world (1)

walt-sjc (145127) | more than 6 years ago | (#20638563)

They can do so through a small IPv4 portal rather than needing an entire class A address space. Net gain is still large, but not large enough to solve the problem. IPv6 is still needed quite soon.

Two years! (0)

Anonymous Coward | more than 6 years ago | (#20639211)

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

Re:DHCP in an IPV6 world (5, Insightful)

afabbro (33948) | more than 6 years ago | (#20639475)

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. It may take a little longer (months?) before people start really feeling any pain from that at the end-user level. But its the critically important point for people to realize.


Son, they've been saying that for 15+ years.

Yes, there is a limit. But once IPV4 address space at the "top level" becomes scarce, it will be handled according to the rules of any scarce commodity - it'll become more expensive. That will encourage efficiency, free space from wasteful users, etc. Then we'll get close again, lather rinse repeat, etc. We will eventually hit the point of "full" but it's not like in September 2010 suddenly there will be no more routable IPs for the next system that needs one.

Re:DHCP in an IPV6 world (1)

balbeir (557475) | more than 6 years ago | (#20637059)

One thing that has never been clear to me is how you do dynamic dns updates in an autoconf scenario.
It's the DHCP server that typically does this on behalf on the client.

Can someone shed a light on that ?

Re:DHCP in an IPV6 world (1)

hedwards (940851) | more than 6 years ago | (#20637685)

The same way that it's done under ipv4 with small servers. The server itself informs the DNS of the change and the DNS propagates the change. The DHCP server presently only does that if it is told to do so and knows that there are servers on the network, which mac addresses they have etc. They don't do this if you're running a small server over a private network unless you've specifically set it up like that.

Most if not all of the dynamic DNS outfits provide a utility that will do the updating. I see no reason why ipv6 would necessitate a change.

Re:DHCP in an IPV6 world (1)

balbeir (557475) | more than 6 years ago | (#20639359)

Thanks, I was afraid that was the answer.

I was in particular thinking about a server scenario in a datacenter. IPv6 autoconf seems to be attractive even for servers because then renumbers etc... become easy. In the V4 world you'd just use a static ip and be done with it

It seems like a bit of a configuration hassle to configure each server with the key to update the DNS server though and having a DHCP server doing it for you looks like it's easier and more secure.

Having a stateless DHCP do the DNS update would be the best of both worlds but I haven't found any that has that feature.

Re:DHCP in an IPV6 world (1)

grimwell (141031) | more than 6 years ago | (#20640131)

I haven't found a way to do without DHCPv6. See rfc 4704 [faqs.org]

There was a draft rfc, draft-jeong-ipv6-ra-dns-autoconf-00.txt [umn.edu] but it was later rejected [ietf.org] because of scale issues; required management of authorization information for individual hosts.

There is a long thread about ipv6 & dynamic updates located here [ietf.org]

There is a draft rfc for adding a router message to the autoconfiguration of ipv6 addresses to include sending dns addresses. The draft is available here [ietf.org] . Of course after the draft is finalized kernel(linux, *bds, windows, etc) support will need to be added.

The ipv6 autoconfig is nice but lacks the useful things(ntp, dns, etc) that DHCP provides.

Re:DHCP in an IPV6 world (1)

Bacon Bits (926911) | more than 6 years ago | (#20637081)

Short answer? NAC and 802.1X.

You don't take access. We grant it to you.

Re:DHCP in an IPV6 world (1)

Vancorps (746090) | more than 6 years ago | (#20637083)

Good luck figuring that out over a VPN connection.

I can see both sides of this argument pretty easily. Perhaps you have multiple gateways for different reasons but are too dumb to subnet/VLAN. Of course with 802.1X authentication I'm not sure how that would work without DHCP given that an address is assigned dynamically and RADIUS accounting determines when and if they gain access and for how long among other features.

Theoretically it could be done without DHCP although I imagine the software clients would have to get modified to support that.

Also, some of us use DHCP on non-routed networks like internal security cameras, IP phones, and IPTV.

Re:DHCP in an IPV6 world (4, Informative)

thegameiam (671961) | more than 6 years ago | (#20637115)

Yes, you can get your IP address and router, but you won't get a DNS server. I don't know about you, but I'm not a huge fan of manually entering 128-bit addresses...

IPv6 Autoconf resembles bootP or inverse-arp more than it does DHCP. Also, DHCP has steadily developed a bunch of knobs over the years so that (for instance) IP phones can be told about which TFTP server to use - that sort of functionality doesn't exist in v6 autoconf today. Not to say that it never will, but v6 autoconf doesn't currently have anywhere near the capabilities that v4 DHCP does.

Re:DHCP in an IPV6 world (4, Informative)

arivanov (12034) | more than 6 years ago | (#20637601)

DNS server, NTP server, LDAP server and the rest of the zeroconf paraphernalia. In other words most of what it takes to set up a client to manage it. IPv6 autoconf does none of that.

How do you type in the A6 record? (0)

Anonymous Coward | more than 6 years ago | (#20637187)

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?

Re:How do you type in the A6 record? (1, Funny)

Anonymous Coward | more than 6 years ago | (#20637539)

Now, how, after autoconfiguration, do I get my machine's name "arthur" registered as belonging to this new, autoconfigured IPv6 address?

Fairies.

Or are you really advocating putting a bunch of Domain Fairies out of a job by using some automated DHCP thing?

Re:How do you type in the A6 record? (1)

profplump (309017) | more than 6 years ago | (#20637603)

The auto-configured address is static. If you wanted a DNS entry you'd have to set it up -- once. After that the machine would get the same address time and time again.

Then in what way is it autoconfigured? (0)

Anonymous Coward | more than 6 years ago | (#20637801)

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

Re:DHCP in an IPV6 world (4, Informative)

Imagix (695350) | more than 6 years ago | (#20637273)

And DHCPv6 provides for more information than merely the IP, Subnet, and Router addresses (say, DNS, boot server, configuration file name, time server, etc). And yes, you can configure a network in such a way that the device is required to be known by the DHCP server before it is allowed to talk (off of its local network anyway...).

Re:DHCP in an IPV6 world (5, Informative)

markom (220743) | more than 6 years ago | (#20637317)

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.
I beg to differ.

DHCP combined with modern network infrastructure allows network administrators complete control over all addressing issues in the network - including preventing non-DHCP hosts from participating in the network (called DHCP snooping) and location-based services ("DHCP option 82"). DHCP is so much more than just a kludge to get an IP address to the host. Scalability of DHCP allows network administrators to append information such as DNS, NTP, TFTP (for IP Telephony/TV) server information and so much more - default gateway, static routes just to name few. All this is pretty much lacking from IPv6 autoconfiguration.

That's why we tend to like DHCP ;-)

Marko
CCIE #18427

Re:DHCP in an IPV6 world (1)

GIL_Dude (850471) | more than 6 years ago | (#20637553)

Don't forget the WPAD information so that web browsers can find their proxy server. Handing this out in DHCP is faster for the browser than just configuring WPAD in DNS (it can be done both ways, and should be for redundancy - but setting it in DHCP generally results in better behavior).

Re:DHCP in an IPV6 world (0)

Anonymous Coward | more than 6 years ago | (#20637831)

How does DHCP allow you to set static routes? The only way I've seen is basically useless due to classless IP routing now being the most widely deployed routing standard.

Re:DHCP in an IPV6 world (1)

Anomalyst (742352) | more than 6 years ago | (#20640151)

Theoretically the latest DHCP specs should do allow us to do everything we want, static routing wise. Originally DHCP only defined a host route and Windows 2000 would not even accept and act on that value. A new option allows CIDR definition, but Windows 2K3 implementation got confused when the lease renewed. It looks like they deleted the DHCP supplied route and the re-insertion after the renewal did not seem to put it back correctly and the traffic preferred the default route. Boy was that a joy to track down. Terminal servers that had been running untouched for weeks suddenly lose connectivity to hosts on the other side of the internal WAN). Maybe MS has fixed it in the last 6 months, I doubt it. I haven't tried any Linux stuff in the mix.

Re:DHCP in an IPV6 world (1)

Sique (173459) | more than 6 years ago | (#20639113)

The Siemens Deployment Service for IP phones (Siemens optipoint 4xx) even sends VLAN number and Gatekeeper address via DCHP, using option 43.

Re:DHCP in an IPV6 world (1)

Corporate Troll (537873) | more than 6 years ago | (#20637645)

I like the fact that you can map an MAC address to a IP address in DHCP. So, my machines in my network always get the same IP address, even though I all set them to be dynamically allocated. Autoconfig removes this ability, as far as I can see. DHCP is not only used to allocate dynamic addresses, but also to assign fixed addresses.

You can ever set your DHCP server in such a way that it won't allocate IP adresses to unknown MAC addresses. Sure, one can spoof a MAC address, I know, but to the clueless user it's one more barrier.

Re:DHCP in an IPV6 world (1)

grimwell (141031) | more than 6 years ago | (#20639341)

I like the fact that you can map an MAC address to a IP address in DHCP. So, my machines in my network always get the same IP address, even though I all set them to be dynamically allocated. Autoconfig removes this ability, as far as I can see.


IPv6 autoconfig for addresses uses the machine's MAC address to generate its IPv6 address. The method is referred to as EUI-64. There is a tutorial here. [ieee.org]

As long as the machine's MAC doesn't change(e.g. generating a new MAC for privacy reasons) it will configure itself for the same IPv6 address every time.

Re:DHCP in an IPV6 world (3, Insightful)

TemporalBeing (803363) | more than 6 years ago | (#20637725)

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.
As others have said, DHCP does so much more.

I run DHCP on my home network to setup: DNS, WINS, Gateway, IP Address, NTP (Time), and other services. I also use it to record MAC addresses for security reasons, and to easily grab them so that I can configure static IPs and DNS names for specific systems without having to ask people for their specific MAC (unless they're coming in wireless...then they need to to get access anyway...).

Point is, it gives me an easy way to manage my network. And honestly, I was looking forward to playing around with IPv6 in the same manner on my home network (because I could, and wanted to experiment), but some things just aren't ready for it yet, and the lack of a DHCPv6 server (at the time) to manage the auto-configuring was an issue too.

Additionally, I have played with IPv6 with its auto-config, which at least under Windows 2003 is a joke as it is a half-baked implementation that is just plain broke. Half the time it works, and half the time it doesn't. And when it doesn't, it is seriously borked, and breaks everything else too. (And I was only running a set of 6 systems (4 servers, and 2 clients) in my test network.) It took a lot of time to get systems reconnected when things failed out due to IPv6 addressing not working. Haven't tried it much under Linux yet...but I would still have Windows clients to support, and VPN and other software that would need supported. (Software I don't control the version or support on...work does.)

Any how...DHCPv6 would have made supporting that test network a lot easier, and actually would have kept it functional. I cannot imagine what kind of problems admins will have trying to deploy IPv6 with auto-config on a larger network. (Imagine, your computer gets a new IPv6 address just because you rebooted...not make that your server and you could really screw up your network quickly.)

Re:DHCP in an IPV6 world (2, Interesting)

TheSkyIsPurple (901118) | more than 6 years ago | (#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)

DHCP plain sucks (1, Informative)

Anonymous Coward | more than 6 years ago | (#20636973)

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

Re:DHCP plain sucks (2, Interesting)

Epsillon (608775) | more than 6 years ago | (#20637473)

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

Re:DHCP plain sucks (1)

TheRaven64 (641858) | more than 6 years ago | (#20638975)

I had been wondering how to get DNS to Just Work [TM] over an autoconfigured v6 interface for a while.
I might be talking nonsense, but isn't that what anycast is for?

Re:DHCP plain sucks (1)

Epsillon (608775) | more than 6 years ago | (#20639899)

I might be talking nonsense, but isn't that what anycast is for?
It is discussed in RFC 1546 [ietf.org] , although notice that it says

The idea is that the Internet might establish that a particular anycast address is the logical address of the DNS server. Then host software could be configured at the manufacturer to always send DNS queries to the DNS anycast address. In other words, anycasting could be used to support autoconfiguration of DNS resolvers.
"Could" being the operative word. Right now, either I don't know how to implement it (VERY likely) or the OS doesn't support it. I don't see getaddrinfo() doing this or, at least, man 3 getaddrinfo on 6.2-RELEASE-p7 doesn't mention anycast, nor does man 5 nsswitch.conf refer to anycast over IPv6. Am I looking in the wrong places? It would certainly make it easier to deploy IPv6.

this is boring (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#20636997)

I want a flamewar about. You choose the subject, I'll post the rant.

Thanks!

Re:this is boring (1)

Keith Curtis (923118) | more than 6 years ago | (#20637289)

Topic: Ranting - Useful tool for stress relief or defense mechanism for frustrated closet gays?
Discuss.

Why did everyone completely ignore ISO? (1)

Colin Smith (2679) | more than 6 years ago | (#20637009)

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.

 

Re:Why did everyone completely ignore ISO? (2, Informative)

T-Ranger (10520) | more than 6 years ago | (#20637271)

I guess it boils down to: because the full ISO stack never worked.

First off, it was never "finished", insofar as many features available in other things were/are not available in OSI.... Given the level of "optional" features of OSI, in practice, full systems never did manage to communicate with each other. Given the complexity of the standards, building software, and debugging things, was very, very hard.

I am more then willing to grant that some very specific bits coming out of the OSI process were good, and are still used. Some of x500. Some of WAN routing protocols. Some of a few low level WAN media stuff. Some of ATM. Etc.

The problem - and this is a lesson that the IPv6 people know - is that "actually works" was never a specific requirement of the OSI process. And with the "Internet/RFC" process, "actually works" is about the only firm technical requirement (some legal patent ones, as well).

Missing DNS (4, Insightful)

thegameiam (671961) | more than 6 years ago | (#20637019)

IPv6 Autoconfiguration is close but no cigar in a couple of signignificant ways:

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

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

Re:Missing DNS (4, Informative)

Znork (31774) | more than 6 years ago | (#20637239)

"3) Just try it with VMWare or other virtualization software. Ouch. There's a whole lot of borked there."

Eh, what?

As far as I could tell, as soon as I started radvd on my gateway all my xen guests autoconfigured their global v6 address. Perhaps you have a VMWare specific issue?

"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?"

Obviously you dont have a server-hardware ip address to use for a true server service. You dedicate an IP address to the actual service so you can move it around freely decoupled from the hardware and any other services on the box. (And to tie back to your earlier point; if you're virtualizing, there's no connection between the hardware and the MAC address anyway).

When you have a bazillion ip addresses it's not like you have to save them for a rainy day.

Re:Missing DNS (1)

thegameiam (671961) | more than 6 years ago | (#20637389)

I haven't used Xen with v6. VMWare had problems getting the guest to do the autoconfiguration instead of having the host do it - that provides a vector to get from guest -> host...

You do have a fair point: I should probably consider that a VMWare issue rather than an autoconf issue, but the general v6 approach is to have a single gigantic broadcast domain per "site," instead of learning the lessons we all have in the past 10 years about the benefits of small layer-2 islands connected with layer-3... So the natural way of doing things in v6 will encounter this problem.

Re:Missing DNS (2, Insightful)

Znork (31774) | more than 6 years ago | (#20638183)

"VMWare had problems getting the guest to do the autoconfiguration instead of having the host do it"

Could be a bridging issue with VMWare. As long as the virtualization software acts as an unfiltered bridge, v6 autoconf really should work.

"instead of learning the lessons we all have in the past 10 years about the benefits of small layer-2 islands connected with layer-3."

I agree in part, but it depends on how you look at it. I think the idea is to use it as huge, very sparsely populated layer-2 islands connected with layer-3. And with the default being a /48 per end site, you get 65k subnets per end network (enough for most corporate subnetting purposes). Which does feel like a certain level of overkill; I'm not sure I'll really need 65 thousand internets worth of addresses for my home network in the immediate future.

I think they did design it with such levels of waste in mind tho, so one can see it more as an indication as to the reason for using such a rediculously large address space.

4) Obviously you wouldn't want to use it for a tru (1)

dpilot (134227) | more than 6 years ago | (#20638839)

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?

wasn't going to use it anyway..... (4, Interesting)

Lxy (80823) | more than 6 years ago | (#20637025)

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.

Re:wasn't going to use it anyway..... (4, Informative)

jd (1658) | more than 6 years ago | (#20637885)

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. True, you wouldn't use the router advertisement protocol, but there are major advantages to having lightweight protocols that can be added to as extra needs develop, as opposed to having one monolithic protocol that requires excessive space on the network and heavyweight processes to churn over.

4 years and counting (2, Informative)

GNUThomson (806789) | more than 6 years ago | (#20637935)

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.

Re:wasn't going to use it anyway..... (1)

_KiTA_ (241027) | more than 6 years ago | (#20638941)


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.


Forgive me if I'm wrong, but that sounds less like "DHCP is awesome" and more like "Lazy devs have added extensions to DHCP rather than implement a proper auto-configuration protocol for their other services."

Can't really blame V6 Autoconfig if it's not up to spec with... something else that's not following specs.

Re:wasn't going to use it anyway..... (1)

jc42 (318812) | more than 6 years ago | (#20639829)

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.

So can it also tell my wife where her keys are? If so, I'll be adopting it right away.

(I've been looking for a key-chain gadget that combines GPS and wifi capabilities. I could write my own program that queries it and tells me where she left it. Then the only remaining problem would be the not-so-good accuracy, to within about 5 or 6 meters, for "civilian" GPS. That's not good enough; we need access to the under-a-meter accuracy of the military channel if we're gonna find those keys).

Not just corporate (4, Informative)

Dolda2000 (759023) | more than 6 years ago | (#20637033)

From what I've been able to tell from the discussions on the IETF's IPv6 mailing list, it probably won't just be corporate networks going with DHCPv6. The greatest problem with IPv6 autoconfiguration (probably since its inception) is the fact that while you get a network address, you don't get any information about available DNS servers, which no modern IP node can do without in reality.

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.

Agreed... Re:Not just corporate (2, Interesting)

cwolfsheep (685385) | more than 6 years ago | (#20637479)

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.

Re:Agreed... Re:Not just corporate (1)

Todd Knarr (15451) | more than 6 years ago | (#20638827)

Note that that won't restrict use of your nameservers. It just means a rogue machine has to find out what the IP addresses of the nameservers are so it can configure them. That may be easy if the rogue machine is an unauthorized laptop belonging to a legitimate user who's got the configuration of his desktop readily to hand to copy information from.

And autoconfig pretty much makes it impossible to restrict access to the network at all. Autoconfig'd machines probably can't get through the router and may not be able to get DNS service because they don't know the nameserver IP addresses, but they can still talk to everything in the local broadcast domain. That's sufficient for running an Nmap scan of the segment to find out what's there.

Three Reasons (0)

Anonymous Coward | more than 6 years ago | (#20637095)

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.

Who really expected this? (1)

mkithara (589429) | more than 6 years ago | (#20637113)

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.

Why Not Both (5, Insightful)

maz2331 (1104901) | more than 6 years ago | (#20637145)

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?

cisco! (0)

Anonymous Coward | more than 6 years ago | (#20637147)

we MUST go to IPV6! I own $10k in Cisco stock that needs to go to $20k before I break even.

OK let me get this straight... (4, Insightful)

Spy der Mann (805235) | more than 6 years ago | (#20637217)

IPv6 isn't that good because DHCP has been updated to support IPv6?
O.O *blink blink* O.O

Bad eyes morning (0)

Anonymous Coward | more than 6 years ago | (#20637281)

I read that as *bling bling* and wondered why a rap star between two topless chicks cared anything about IPv6.

The real reason... (2, Insightful)

yogi (3827) | more than 6 years ago | (#20637309)

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.

Re:The real reason... (1)

igjeff (15314) | more than 6 years ago | (#20638653)

>Nope, you won't get any business benefit.

Here's a problem.

I consider the basic ability to grow the IT infrastructure (and therefore the business) to be a business benefit.

Re:The real reason... (1)

pacman on prozac (448607) | more than 6 years ago | (#20639179)

That's a problem for Internet facing companies who require public address space but not so much for places with only a few public IPs.

Many companies will find it hard to justify the investment in ipv6 while there's plenty of space left in 10.0.0.0/8.

Re:The real reason... (0)

Anonymous Coward | more than 6 years ago | (#20638903)

Umm hello, end-to-end? The Internet was built on the concept of end-to-end communication, a concept which today does not exist. The Internet is, quite frankly, BROKEN, and IPv6 is a way to fix it.

Myself, my landlord, and his entire family, live off of 1 visible IP address. Yes, fine, we have dozens of millions of internal IP addresses we can use. Whoop-di-doo. If all I wanted the Internet for was to communicate with my landlord and his family, that would be absolutely fabulous. But it's not.

The Internet today is far more centralized than it needs to be, and waay more centralized than it should be. The Internet today is broken up into the Hosts and the Host-Nots, for no good reason. "Peer-to-peer" protocols these days are ludicrously centralized, and all because it's really annoying to punch holes through NATs.

In conclusion, DIE NAT DIE. To further summarize, every time I hear the phrase "IPv6", I imagine NAT dying a slow and horrible death. And it makes me smile. No exaggeration, even if I had to pay $100/mo. for 3 kilobit/second access that was full IPv6, I would switch in a heartbeat. NAT IS EVIL. (Well, more specifically, anything that prevents all of my and my landlord's devices in a totally end-to-end fashion is evil). Until I can get that, I'm stuck being a Host-Not :(

Choosing a story title... (4, Informative)

monkeySauce (562927) | more than 6 years ago | (#20637443)

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

Re:Choosing a story title... (1)

soliptic (665417) | more than 6 years ago | (#20637843)

<GrammarNazi>

The (fictional) Editor, given his/her job title, should have known better than to choose a title with a glaring grammatical error.

"Less" is used for continuously variable amounts. The correct word when dealing with discrete quantities is "fewer". Hence, "less oil", but "fewer barrels of oil".

</GrammarNazi>

Re:Choosing a story title... (1)

TeknoHog (164938) | more than 6 years ago | (#20638787)

"Less" is used for continuously variable amounts. The correct word when dealing with discrete quantities is "fewer". Hence, "less oil", but "fewer barrels of oil".

<ScienceNazi>
The amount of oil is not continuously variable. It's "fewer molecules of oil". ;)
</ScienceNazi>

Headline backwards? (1)

evilviper (135110) | more than 6 years ago | (#20637501)

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.

Stop making excuses! (3, Funny)

vertinox (846076) | more than 6 years ago | (#20637521)

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.

address space (4, Interesting)

SuperBanana (662181) | more than 6 years ago | (#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

Re:address space (2, Informative)

Detritus (11846) | more than 6 years ago | (#20637979)

Because they were pioneers. As in other things, pioneers take the risks and reap the benefits, or get 30 arrows in their back.

Re:address space (1)

necrogram (675897) | more than 6 years ago | (#20639709)

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.


Its a litle more that once of the bing things is it requires a lot of code changed to support IPv6. I'd like to mopve to v6, comma but no one i talk to (i.e. my provider) uses it yet. Now before I get the standard "get a new provider" spiel, I'm a state agency, and my provider is another state agency.

the same holds true for all my edge devices. A wholesale updates of them would be needed as well. And i'm not talking just desktops. I also got IP phones and lab instruments just to name a few.

Its alot to start to consider from a network dude's point of vew

Re:address space (1)

zenray (9262) | more than 6 years ago | (#20639875)

The Last time I checked Zenith Electronics had an entire class B block.

IPV6 and Privacy. (1)

TheNarrator (200498) | more than 6 years ago | (#20637693)

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.

Space makes waste? (1)

HTH NE1 (675604) | more than 6 years ago | (#20639805)

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.
Parkinson's Law: Programs expand to fill the memory available to hold them.

(And here I was hoping to post, "Reasonable limits aren't.")

premature... (2, Interesting)

pjr.cc (760528) | more than 6 years ago | (#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.

Summary doesn't quite ring true. (1)

nsayer (86181) | more than 6 years ago | (#20638385)

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.

mDNS instead of DHCP for service anouncement (1)

takev (214836) | more than 6 years ago | (#20638535)

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.

You're not going to have much choice... (0)

Anonymous Coward | more than 6 years ago | (#20638565)

In a year or two, three, you're not going to have much choice. The IANA pool of unallocated addresses is declining very rapidly [potaroo.net] .

Imperfect though it might be, IPv6 is the future...

Audit /8 nets & Portable IP space are the issu (1)

ejoe_mac (560743) | more than 6 years ago | (#20639567)

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 [arin.net]

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

Too much magic (2, Insightful)

sjames (1099) | more than 6 years ago | (#20639847)

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:

  1. Just pick one and use it
  2. Actually assign both and just pick one when there is an overlap otherwise use the most specific route.

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>