Slashdot Mirror
Bind, Safer DNS, and IPv6
resistant writes: "This article at Network World Fusion (seen at Linux Today) says, "In addition to DNSSEC, BIND 9 features support for IPv6, the ability to run on multiprocessor systems and improved scalability for handling large domain name zones." The urgent need (by Nike anyway, heh-heh) to forestall easy domain hijacking could be the sleeper issue that finally ushers in universal implementation of IPv6."
I must be a moron. I can't get NetSol to change my contact information, delete a domain, or change the technical contact info on a domain.
I've had to do updates at "NetSOL" several times, and these people are scary. I swear they purposely make their site and procedures nearly impossible to decipher. For what it's worth, I stopped having excessive trouble with their automated email-verification scripts (this was a while ago) after realizing (after much hair-tearing) that it is extremely important to be sure that the lines are not wrapped by your email client, in the "template" forms that you email back to them. Also, there must be a space between the colon at the end of each record-descriptor, and the content following on that line (if any). Or, is it must not be a space? Geez, emulate whatever is on the other lines, you know?
It's been a while and this may be obsolete, or slightly mangled in exact detail. I've never had to resort to the infamous fax procedure, and can offer no useful advice on that except to keep on hand a bottle of Aleve, or "other" measures to relieve pain and suffering.
I've since snuck out the back way to a more friendly (OpenSRS reseller) registrar with password protection and decent security, not to mention immeasurably more useable automated scripts for Web-access account management.
A truly excellent pizza parlor is a delight unto the heavens. Treasure the sauce and the toppings!
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Which could be one of the things holding v6 deployment back... If end-to-end IPSEC hasn't been deployed in IPv4, simply "mandating" it in IPv6 doesn't make it easier to do. It just ensures that any IPv6 host might accept IPSEC packets from you--- about what you can assume today. (The mere presence of IPSEC capability on a host says nothing about your ability to use IPSEC to communicate with them.)
Mandatory Quality of Service
Lots of IPv6 marketing claims "improved QoS". Most of these claims seem to be based on the presence of a "flow identifier" field in the IPv6 header. A flow identifier alone doesn't do any good without some system to identify meaning to it. Again, QoS doesn't become easier to implement and deploy just because IPv6 requires it. Just because the feature's there doesn't mean the router does anything meaningful with it. (I would welcome any correction--- perhaps I just haven't seen the relevant specification?)
Guaranteed mobile IP addressing
Sure, IPv6 mobility is a better design than current IPv4 mobility. (Now, I happen to think that mobility needs to be handled above the IP layer, but that's an argument for another time...) But there's nothing "guaranteed" about it. In fact, IPv6 mobility depends on having a "AAA" structure, the design of which is still being worked out. Even with the architecture there, "guaranteed" is too strong a word--- only a network's willingness to provide the service gives you the ability to use it.
Automatic Network Configuration
"for Hierarchies?" I don't understand that. Many people view autoconfiguration of devices as a useful thing. But there's no direct support for ad-hoc networking, which is what I tend to think of as "automatica network configuration".
Simpler Headers == Quicker Routing
Software implementation == magnitudes slower routing. So you see a big disadvantage to going to "native" IPv6 until people start creating forwarding hardware for it. Which is expensive, since now you have to have a 128-bit data path (or 256-bit, if you route on source and destination--- as you do for multicast) rather than a 32-bit or 64-bit data path. Perhaps you're referring to the simpler option design? I admit it's worlds better. But in the real world, most packets don't come with options (and those that do get punted up to software), so the real cost is routing lookups. IPv6 claims to make routing tables smaller (using the strict addressing hierarchy)--- we'll see--- but even if they stay the same size, the prefix match gets longer--- which requires either more memory accesses or bigger ternary CAMS. No guarantee of quicker routing in any way.
Mandatory Anycasting
I don't like anycast. It's generally not responsive to higher-level failure, but since it's at the network level, you might be stuck with an unresponsive server for a while. Multicast is a better design decision in the local area.
Mandatory Multicasting
We've had (multi-source) multicast for longer than the Web. It hasn't really been deployed worldwide for a variety of reasons. (Hard to route, hard to bill, hard to debug...) Making it "mandatory" only increases wariness about deploying IPv6. Also, single-source multicast (SSM) looks like it may actually go somewhere, has no address shortage, and is much easier to route and debug. But you don't need to go to v6 to use it.
Mandatory Connection Fail-over Support
I must plead ignorance to this one, too. However, IPv6 can make multihoming your network a much more difficult problem, since you receive different address ranges for your machines from each of your ISPs. Yet, the entire IPv6 address is the endpoint identifier. So, esentially, your choice of address locks you into a particular ISP. Various tunnelling designs have been suggested to improve this, but they increase the complexity of the network. (To be fair, it's not too much worse than multihoming in IPv4--- unless, like Stanford, you already have an AS number for BGP and are not likely to get a TLA in IPv6. Why upgrade?)
IDRP Routing Protocol
Again, I must plead ignorance. But why can't this routing protocol (if it's a good idea) be done with v4?
Excellent point, thank you for making it. The deployment of an IPv6-aware DNS server is just one small step. It doesn't address the larger issues involved in deploying IPv6. And I'm somewhat annoyed at CmdrTaco for implying that it does. If all people want is DNSSEC, then that's all they're going to install and configure--- the fact that the software can handle IPv6 is going to be of very limited interest to them.
Or possibly even a source of annoyance if their software starts sending out v6 address requests before looking for the v4 address. I know somebody who has gotten burned by this--- he upgraded his system to support IPv6. The name lookup tries AAAA first, then A. Well, Stanford's load-balancing DNS server returns the wrong thing to the first request ("name not present", basically, rather than "that name exists but we don't have any v6 addresses"), so the nameserver caches the negative answer and returns it in response to the 'A' query as well. Oops, suddenly he can't log into the computer cluster using the normal domain name. It's true that this is a bug with the load-balancing software, not IPv6. It's just yet another hurdle to overcome.
While IPv6 has a lot of transition features, it nonetheless remains the case that as soon as people start using it, there will be IPv4 sites that can't access IPv6 sites and vice versa. Some will run both protocols, but if v6 is to be made use of, there are going to be many machines that don't, and transparency is going to be awkward if not impossible.
How's it done?
--
You are not alone. This is not normal. None of this is normal.
The following links are some that i've come across. They are rather interesting at times:
A how-to for stealing someone's domain name, which was a ddresed in the article. Furthermore, the specs for these protocols and implementations can be found here and here. There was also a critical interview calling for the implementation of these more secure systems in order to prevent the holes in the current system..
The only way that IPv6 will be implemented is if all the OSes get their TCP/IP drivers updated (unless this thing is backwards compatible, which doesn't seem to be the case implied by the drastic changes). The current IP standard has a possibility of letting you access a little over 4 billion IP addresses. Since there's 6 billion people on the Earth, and the initiative has been set to give every person at least some kind of access to the 'net, this does need to be updated. But what does this mean? Will subnet masks now resemble 511.511.511.0? Or something similar?
Hopefully, this will be implemented seamlessly, with just a simple driver update. However, I personally think that Nike deserved getting its back orifice reamed; after all, they're the company that has a starting salary of $0.08 an hour.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
You forgot the sheer lack of unique IP-adresses.
:)
;)
(i'm going to use cut&paste from a calculator now
IPv4 has a 32-bit address-range (duh!) which means there are 4,294,967,296 different addresses. Give everyone on earth a unique address, and there won't be enough of them already! If everyone were to connect their coffee makers, tv-sets and such; well, you see my point.
IPv6, on the other hand, has a 128-bit (!) address-range instead. This'll give us 3,4028236692093846346337460743177e+38 addresses. This leaves enough room for everybody, including their home/work-appliances, for at least the next 10 years.
THAT's the *real* difference.
I'm tellin' ya!
Not all applications have to be re-written. There have been IPv6-compliant networking functions (inet_pton(), etc. etc.) out there for a while now, so if you have a clue you have been using them.
Sun, who provides a dual stack (IPv4 and IPv6) in Solaris 8 has a "scrubber" utility that will help go through your code and remove IPv4 only funtions and such.
Applications written to use the "newer" networking code work fine in IPv4 and IPv6 - like BIND9.
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
At every IETF meeting I've been to, including the most recent one in Pittsburgh, the IPv6 discussion went like this:
Q: Is microsoft going to support it in a release OS?
A: No, but microsoft research has a stack in development
Q: Does Cisco support it?
A: We're working on it.
Then half the room walks out the door, and all that's left is the Kame project talking about how they can tunnel their ipv6 site through ipv4 to see the dancing turtle.
IPv6 is dead till it ships in a microsoft stack. When it does, IPv6 will be real instantly.
And you can quote me on that.
--
What happens when you outlaw guns