Slashdot Mirror


After IPv4, How Will the Internet Function?

An anonymous reader writes "36 countries in the world have over 100% per-capita usage of mobile phones, and this is driving a real crunch on IPv4 addresses as more and more of these devices are data-capable. The mobile network operators are acting fast to deploy IPv6, and T-Mobile USA has had an IPv6-only trial going on for over 9 months now using NAT64 to bridge to IPv4 Internet content. It is interesting to note that the original plan for IPv6 transition, dual-stack, has failed since IPv4 addresses are effectively already exhausted for many people who want them. Dual-stack also causes many other issues and has forced the IETF to generate workarounds for end users called happy eyeballs (implying that eyeballs are not happy with dual-stack), and a big stink around DNS white-listing. How will you ensure that your network, users, and services continue to work in the address-fractured world of the future where some users have only IPv4 (AT&T ), some users have only IPv6 (mobile and machine-to-machine as well as developing countries), and other Internet nodes have both?"

10 of 320 comments (clear)

  1. Dual stack failed? by Just+Some+Guy · · Score: 4, Interesting

    It seems ludicrous to claim that the dual stack idea has failed when more and more devices are suddenly finding themselves with IPv6 addresses and are putting them to use. My home and work LANs are dual stack and everything Just Works. For being a failed experiment, it works amazingly well in everyday usage.

    --
    Dewey, what part of this looks like authorities should be involved?
    1. Re:Dual stack failed? by Chang · · Score: 5, Insightful

      Dual stack works but is has failed in the sense that it can't be the singular solution during the transition from IPv4 to IPv6.

    2. Re:Dual stack failed? by Nurgled · · Score: 4, Interesting

      Engineering of application-layer protocols is far easier when everyone is addressable. The deployment of NAT has had a cascading effect on many application layer protocols that would have had a simple, obvious implementation were every node equally addressable. Instead, every new application protocol has to consider and work around NAT.

      So sure, as we stand today that ship has sailed and NAT has created a hierarchy of nodes that is unavoidable in today's network engineering, but I wonder how much innovation has been stifled by time spent working around NAT.

  2. Easy.. by Junta · · Score: 5, Interesting

    Thanks to finally embracing NAT64, this becomes easy.

    If you are providing 'server' access, you pretty much *have* to get an IPv4 address, and preferably an IPv6, but not absolutely required for now. Short term, don't sweat it, medium term go dual stack at first opportunity that presents itself, long term you may take down the IPv4 network one day, but don't explicitly plan when that day will come. The common strategy may continue to be ignore v6 entirely, however moving dual stack at your pace ensures that in the slim, but real possibility that your next-hop provider stops IPv4 routing or starts penalizing IPv4 use via unreasonable fees won't put you in a tight spot. The scenario of next-hop penalizing/dropping v4 is the only scenario I see as sufficient motivation to get servers to bother with v6 at all. I think even brand new servers will do what it takes to secure IPv4 space, which may free up some given the next point...

    If you are setting up a network as 'clients', you can get by with either IPv6 or IPv4 for a while. Giving dual stack when available is nice, but whatever you have would be sufficient. ISPs without IPv4 addresses available for new clients should rapidly pursue IPv6 for residential customers and give them most internet via NAT64 on their end. Doing IPv4 private addresses would doom them to crappy service indefinitely, whilst IPv6 would only be semi-crappy for a more temporary interval. If you *really* want v6 to catch on, then start allowing v4 addresses to be carved up more free-market style. All technical experts agree that this would completely fubar the v4 network performance in aggregate, but you would entice adoption of v6+NAT64 with the profitable opportunity to reclaim addresses and sell them to places that *really* need them. The v6 network would be nice and cleanly routed, and getting on the v6 network just becomes that much more important.

    Some would argue that any sort of NAT at the carrier plays right into the hands of those who hate P2P networks, including NAT64 as those behind NAT64 are unreachable by peers who are v4 only. However, the reality is there are two possible outcomes, residences getting 10/8, 172.16/12, or 192.168/16 which *completely* breaks P2P (and probably many wireless routers presuming those prefixes won't come from the WAN), or NAT64 where the P2P graph may not be as connected, but all v6 peers can reach each other. Since P2P designs are inherently tolerant of unreliable ability to reach peers, this should suffice for a while.

    Major architects in v6 world advocated the dual-stack method as the way to theoretically move on with no thought to the practical motivations to move forward. They hated NAT in every way as it breaks the peering model they hold dear. They hated accepting the practical view that most of the internet are clients and few are servers. If they had embraced it from the beginning, then I suspect most residences would be v6 by now.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  3. This almost out nonsense needs to stop by Sycraft-fu · · Score: 4, Interesting

    Geeks should know better. The way it is talked about, you'd think in a couple days someone will plug in a device and there'll be no more IPs. Not hardly. We are approaching the first milestone in an eventual crunch. That is that there will be no more addresses not assigned to a registrar. The remaining class-As will be handed out to the regional registrars. While that means at the highest level we are "out" that doesn't mean we are out on a user level.

    I'm not saying that we don't need to move to IPv6 but people on /. keep talking like we are going to be out of every single IP address real soon. No, rather we will be starting a process of scarcity. So far there's been no real scarcity of IP addresses. That will change. However all that means is that costs will change.

    That will actually probably be a good thing for IPv6 adoption. If you are a company and want some static IPs and your ISP says "Sure, you can have IPv4 addresses at $30/month each, or as many IPv6 addresses as you want for free," well maybe you decide there's good reason to go with IPv6 and upgrade your stuff.

    1. Re:This almost out nonsense needs to stop by Anonymous Coward · · Score: 5, Interesting

      If you are a company and want some static IPs and your ISP says "Sure, you can have IPv4 addresses at $30/month each, or as many IPv6 addresses as you want for free,"

      That won't work. Problem is, if you are a company without an IPv4 address, you are not reachable by 99% of Internet users, i.e. you don't exist.

      Companies will pay whatever price, though. They have to. But to suggest that the company can solve this by migrating to IPv6 is short-sighted. The company can only solve this by migrating all of its intended customers to IPv6, in other words: they can't.

      You have made me realize an interesting point, though: as long as ISPs do not migrate their users to IPv6, they can charge extortionary prices for the remaining IPv4 addresses; ISPs have an incentive to create this artificial scarcity. Time to call for government regulation? ;)

  4. It will prety much suck for quite some time. by FlyingGuy · · Score: 5, Insightful

    The problem is the asshats that came up with IPV6. It should be scrapped here and now. IPV6 is just plain and simple flat out stupid.

    Using a hexadecimal address was pure stupidity. All you needed to do was turn each segment of an IP address into a word sized ( 64 bit addressing ) or a long sized ( the magic 128 bit ) value instead of a byte sized value since:

    2600000.35.1254.1785

    Is one hell of a lot easier to remember then

    2001:0db8:85a3:0000:0000:8a2e:0370:7334.

    And using the colon for address separation is equally as stupid since that is how we designate port numbers. Ohh wait I know don't forget to surround the unrememberable POS with square brackets!

    To make IPV6 useful it requires anything and everything to have a DNS entry since it is pretty much unrememberable and quite frankly I have devices that I never want in the DNS system yet I will be pretyy much forced to since trying to remember an IPV6 address will give me a fucking stroke.

    And lets not forget you omit parts of the address eg: 2001:0db8:85a3::0000:8a2e:0370:7334 but ONLY once! I mean why did they even bother with this crap, is that supposed to make it easier?

    IPV6 was written by a bunch of head up their ass academics, and even if the members of the committee were not academics their head was still firmly planted in their ass.

    The guys who came up with IPV4 new they would have to work with it and made it pretty damn simple in most respects, but these clowns have turned something that should have just made the address space bigger into to something that will require massive kludges to transition since it will pretty much cause a mandatory replacement of pretty much 90% of the hardware out there.

    Never ever let an academic design anything. They will fuck it up every time.

    --
    Hey KID! Yeah you, get the fuck off my lawn!
    1. Re:It will prety much suck for quite some time. by paul248 · · Score: 4, Informative

      Using a hexadecimal address was pure stupidity.

      Hexadecimal is used because a network is designated by an N-bit prefix, and it's *much* harder to manipulate bits in decimal, especially when each number is 16 or 32 bits long.

      And using the colon for address separation is equally as stupid since that is how we designate port numbers.

      Once you've gone to hexadecimal, using dots to separate the address leads to ambiguity. Is a.b.c.d.e.f.beef.de an IP address or a hostname?

      it is pretty much unrememberable

      With IPv6, your network will have its own 48 to 64-bit prefix. Once you remember that prefix, you can choose your suffixes to be as simple as you'd like.

      you omit parts of the address ... but ONLY once!

      You can only omit one run of zeros, because otherwise the length of each run would be ambiguous.

    2. Re:It will prety much suck for quite some time. by paul248 · · Score: 4, Informative

      It's difficult to manipulate binary digits in hexadecimal, too. I don't see any advantage to this.

      Every hex digit represents exactly 4 binary digits. If you flip a bit in a hexadecimal number, then exactly one hex digit will change. To know how it will change, you only need to remember the binary values of 0-F.

      With decimal, you could flip a bit and change every digit in the number.

    3. Re:It will prety much suck for quite some time. by phantomfive · · Score: 4, Informative

      All you needed to do was turn each segment of an IP address into a word sized ( 64 bit addressing ) or a long sized ( the magic 128 bit ) value instead of a byte sized value since: 2600000.35.1254.1785 Is one hell of a lot easier to remember then 2001:0db8:85a3:0000:0000:8a2e:0370:7334.

      You don't know what you are talking about. Of course '2600000.35.1254.1785' is easier to remember, you aren't using all the bits. If you used the full 64 bits, it's going to be longer no matter what base you are using. Your hex example, if you converted it to decimal, would look just as bad: 536939960.2242052096.35374.57701172. It's not actually easier to remember.

      There is also a shortcut built in for IPv6 addresses. For example, if you had an IPv4 LAN with addresses in the 192.168.0.1 range, you could represent them in IPv6 with ::FFFF:192.168.0.1. Not particularly harder to remember than an IPv4 address now. IPv4 was designed by people who thought before talking. Unlike you, apparently. Work on that: try to figure stuff out before blathering.

      --
      Qxe4