Slashdot Mirror


One Step Closer to IPv6

gbjbaanb writes "IPv6 came a step closer yesterday as ICANN added IPv6 host records to the root DNS servers, reports the BBC. 'Paul Twomey, president of Icann which oversees the addressing system, told the BBC News website there was a need to start moving to IPv6. "There's pressure for people to make the conversion to IPv6," he said. "We're pushing this as a major issue." The reason for the urgency, he said, was because the unallocated addresses from the total of 4,294,967,296 possible with IPv4 was rapidly running out. "We're down to 14% of the unallocated addresses out of the whole pool for version 4," he said. Projections suggest that this unallocated pool will run out by 2011 at the latest.'"

9 of 281 comments (clear)

  1. Re:Sad by tknd · · Score: 4, Informative

    We could probably buy 5-10 years if they could reclaim just the 3, 9, 13, 17, 19, 20, 34 and 40 class As and get over 130,000,000 IPs back.

    130,000,000 / 4,294,967,296 = 3%

    The article says we will run out of unallocated IPs by 2011. The unallocated pool is 14%. It is currently 2008. 2011 - 2008 = 3 years. What makes you think that reclaiming 3% is going to buy us 5 to 10 years?

  2. more the story by trybywrench · · Score: 5, Informative

    The only justification you ever hear for moving to IPv6 is address exhaustion in IPv4. There's a lot of other stuff built into the protocol that will make the net a much better place. Even if IPv4 had the same amount of addresses as IPv6 it would still be worthwhile to switch. Just give this a once over for an introduction

    http://en.wikipedia.org/wiki/Ipv6#Features_and_differences_from_IPv4

    --
    I came to the datacenter drunk with a fake ID, don't you want to be just like me?
    1. Re:more the story by gclef · · Score: 3, Informative

      Yes, lets take a look at those:

      Larger address space
      This is the address exhaustion argument.

      Stateless address autoconfiguration (SLAAC)
      Interesting, but not a selling point for users, and will make administrative management a pain in the ass. Most networks will use DHCPv6 to have records of which host had a given IP address...but they'll still have to run AutoConf to get a default gateway. This kind of split is annoying more than it's helpful.

      Multicast
      This is really only used on the link level, with one or two site-level things. I don't think this will not be used heavily. Also, if you want multicast, it's already available in IPv4. So this isn't really a gain with IPv6.

      Link-local addresses
      End users don't care, most sites won't care. In fact, the only people who do care are the authors of EIGRPv6 and OSPFv6 implementation. This isn't really a gain...just a difference.

      Jumbograms The first possibly interesting thing in the list. It won't be used by many places, but DB->App server jumbograms are a common thing in IPv4, and making those bigger & standard is a reasonable gain.

      Network-layer security
      aka IPSec. Implemented, but key exchange is left as an exercise for the reader. (In other words, it's not happening.) This will be used very, very rarely. This is also something that's already available in IPv4, so not a gain for IPv6.

      Mobility
      Interesting, and also something definitely new....but not actually implemented anywhere. Not clear if this will fly at all.

      No more checksum at the network layer
      I'm not sure if anyone really cares.

      In short, the single biggest selling point for the vast majority of businesses and users really is the extra size. The other stuff is either already available in IPv4, or only useful for some rare cases. In the majority of cases, the extra IP space is IPv6's only real selling point.

  3. I get a surprising number of IPv6 hits... by Omnifarious · · Score: 4, Informative

    I get a surprising number of IPv6 hits on my webserver at home. Most of these appear to be XP or Vista boxes with Internet connection sharing turned on that automatically assign themselves a 6to4 addresses when they have an interface with a public IPv4 address.

    IPv6 with 6to4 is easy to set up, and I'd recommend it to anybody who has a static IPv4 address. You can use NAT-PT so all your IPv6 hosts can still get to the IPv4 network. If you have a couple of DNS servers, you can even set up reverse DNS for your IPv6 network just the way you want using this nice web interface from the NRO.

    I maintain some good links to stuff about IPv6 on del.icio.us.

    I hate NAT. And I think IPv6 can be just as secure. Partly because a 64-bit address space is really hard to effectively randomly probe working addresses and partly because it's fairly easy to configure a firewall to not allow incoming connections.

  4. Re:Great, IPv6, an insecure protocol by Just+Some+Guy · · Score: 4, Informative

    Lest anyone think this jackass is correct:

    IPv6 barely supports firewalls or NATs, allowing any Joe Sixpack to see what your secured corporate network topology is like from anywhere.

    It is not up to the protocol to support the hardware. And anyway, all good firewalls support IPv6 already. NAT? It's there if you're dumb enough to want it.

    It also does not support reserved IP blocks... change ISPs, and you are forced to re-ip your whole network.

    Step one: update your router to the new netblock.

    Step two: sed -i'' 's/^old:net:block/new:addr:ess/' db.mydomain.com; rndc reload

    Step three: laugh at people who go around changing ISPs all the time.

    Of course, IPv6 has -zero- hooks for IP level encryption, so this has to be handled at the trensport or app level.

    If only it support IPSec, "the goal of [which] is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments." Oh, wait...

    --
    Dewey, what part of this looks like authorities should be involved?
  5. NAT Sucks by JSBiff · · Score: 3, Informative

    NAT is, well, better than nothing, which, currently, is your alternative. But I'd hardly call it an "elegant and awesome solution". IMO, ultimately, NAT sucks because you *do not have a globally routable address* for devices in your network. Sure, that gives some security benefits, but makes it a PITA when you do want to open connections directly to a computer or consumer electronic device in your network.

    A few reasons you might want to have a public address inside your network:

    * Direct VOIP telephony (SIP, Skype, various instant messenger clients, run a TeamSpeak Server), etc

    * Running game servers, web server, mail server, etc

    * Remote access (VNC, SSH, etc)

    * Direct file transfer with a friend (I've, from time to time, run into problems with things like instant messenger client based file transfers not working behind a NAT - though they do seem to have somewhat alleviated that problem - I suspect by routing my file transfer through the IM network instead of directly to the other person), or P2P file sharing systems, like Bittorrent - yes, they can usually work behind NATs; but they work better if direct connections could be more easily made).

    Yes, yes, I know about port forwarding. That's fine and dandy as long as you only have a single device per port that you want to allow incoming traffic to. Ultimately, IPv6 is a much better solution to the problem of address space limitations than is NAT. NAT usually requires software to do ugly hacks to get around the limitations of only allowing outbound connections. A simple firewall with every device having a global address is a better solution, because then I can open up as many ports to as many devices as I like, without having to worry about only allowing one device per port.

    I've had a number of times where I've been extremely frustrated by NAT. Often times, if software isn't explicitly written with NAT in mind, and the problems it creates, then it won't work well in a NAT'ed network.

  6. Re:It's a sham - the Internet is mostly dark by BitZtream · · Score: 4, Informative

    While I would love to agree with you completely as I believe ARIN is a bunch of tards (can't speak for the other registries). There are/were technical reasons behind the way IPs are assigned. Machines haven't always had 2 gigs of ram. Maintaining routing tables on a network the size of the Internet was a difficult task, which required aggregating networks at upstream links and all sorts of stuff in a desperate attempt to prevent every multihomed router on the Internet from needing a few gigs to hows the paths to various subnets and determine what path was the best.

    Of course, time goes on, ram is cheap, and doing it now is somewhat easier, but it still requires ram and processing power, and that increases latency and cpu utilization.

    For instance, assume that everyone was assigned address space in blocks of 256 address (class C) and had to show they utilized the address space before getting more as well as prove they continued to use it. Now assume that only half of the address space available was assigned. 2.1 billion addresses in use. Thats approximately 8.3 million class C blocks
    allocated. I'm going to assume thats higher than what we have actually in use these days (not allocated, in use) but bear with me for reference purposes.

    Now, for each packet you route, you have to search through those allocated blocks and find the one that contains the address you're communicating with. You also have to determine which path of the many you may have on your router is the best path to use based on number of hops to the destination (we'll pretend AS hops are real hops for simplicity), include other factors such as your internal weights for a route because its expensive for you to use the OC3 you have rather than the DS3 because you got a great deal on the DS3 but not so much on the OC3.

    You've just spent a lot of CPU cycles trying ot figure out which path to use. Now ... do this on hardware from 10-15 years ago. Well, first off, unless your at a NAP 10 years ago, doing this would require expensive memory upgrades on your routers because most didn't have the ram required to deal with a such a routing table in the first place, now add in the processing increase your going to need because even though you can cache routes and deal with updating the cache only as the external paths change, it only helps so much because those external paths change a lot so your cache hits have to be revalidated more often than you think. God forbid you have a flapping connection, as I can tell you from personal experience, on many routers from 15 years ago, a flap of a line that relays BGP information resulted in a router that was busy for a few seconds dealing with the BGP changes unless it was a fairly high end router.

    So ... the point to all that is, a lot of the way address space was assigned was because the hardware we had to work with 'back in the day' was only capable of so much.

    Okay, so now we can do better, great! Lets readdress everyone ...

    I'm not going to bother going into the complexities of re-addressing a large network, but its rather a pain in the arse and can cost a whole hell of a lot of money in IT resources. So when you look at the big picture and think, 'well, I can readdress now and help deal with the problem and then have to eventually switch to the new protocol (for now, IPv6) eventually anyway OR I can wait till everyone has to switch to the new protocol because of this problem and only do it once'

    It makes more sense to wait and do it at once, save yourself some money, deal with it when everyone else does, and deal with the least amount of work you can until that time. And ... this is how businesses make money, but not doing extra work they are just going to have to do again later if they can prevent it.

    Of course, on that same note, there are plenty of businesses which don't exist yet that will make a killing off the scare of running out of IPv4 address space and the switch to IPv6 ... just like all the ones who made out over y2k fears/bugs.

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
  7. Re:IP6 won't matter til Google supports it by Cajal · · Score: 4, Informative

    This is actually a very important step towards what you want. About two-thirds of the TLDs have authoritative servers which are reachable over IPv6. There's a complete list at my blog - http://www.personal.psu.edu/dvm105/blogs/ipv6/2008/01/ipv6-dns.html

    So you can query the root and .com DNS servers using IPv6. If you want Google to be reachable over IPv6, go talk to Google. Everything higher in the tree is IPv6-enabled now. And Google has an IPv6 allocation from ARIN - they got a /32 2005 - http://ws.arin.net/whois/?queryinput=!%20NET6-2001-4860-1

    I agree that there isn't much content on the IPv6 internet now. So if you want it, yell at the content providers.

  8. Re:127.0.0.1 doesn't have an 8-bit mask by timbo234 · · Score: 3, Informative

    ocalhost (127.0.0.1) has a 32-bit subnet mask, so 127.0.0.1/32

    It may be setup this way on your computer's network settings but the RFC says the whole /8 is valid is part of the loopback:
    http://www.faqs.org/rfcs/rfc3330.html

    --
    Pre-canned Evolution Links for all those Slashdot holy wars.