Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Networking The Internet Technology

Akamai To Offer IPv6 To All In April 110

Posted by Unknown Lamer from the lolcats-over-ipv6 dept.
netbuzz writes "Akamai says that it will offer IPv6 services to its entire customer base beginning next month – a long-awaited move that is expected to be a major boon to the adoption rate of the next-generation Internet Protocol. Akamai hoped to release its production-grade IPv6 services by the end of 2011, but the task proved more difficult than originally anticipated. Akamai has been beta testing its IPv6 services with key customers since last fall."
This discussion has been archived. No new comments can be posted.

Akamai To Offer IPv6 To All In April More

Akamai To Offer IPv6 To All In April

Comments Filter:

  • Probably still waiting for their security software (Score:5, Interesting)

    by BagOBones ( 574735 ) on Monday March 26, 2012 @06:54PM (#39479535)

    Based on my own company checks for readiness I assume the big hold up feature parody with IP4 and IP6 security software and equipment.

    I know many of our security appliances have been able to route IP6 for a long time, but few of them could filter or manage the traffic with any sort of detail close to that of IP4 since the features had not been ported.

    • Re: (Score:1, Funny)

      by Anonymous Coward
      Fuck IPV6. Can't we just have a 36-bit or 48-bit IPV4 and keep everything else the same?

      Think IPv4 PAE.

      • Re:Probably still waiting for their security softw (Score:5, Informative)

        by mattventura ( 1408229 ) on Monday March 26, 2012 @07:21PM (#39479743) Homepage
        How would it be any better? You still would have to replace equipment and software in order to support it. Most high-end equipment uses ASICs for routing, so you wouldn't be able to just do software upgrades to support it.

        • Re: (Score:1)

          by Anonymous Coward

          True, but high-end equipment has been able to run IPv6 for ages now.

      • Re: (Score:1)

        by Anonymous Coward

        No, that would require every OS to replace the TCP/IP stack. No backwards compatibility and no better off than IPv6.

        • No, that would require every OS to replace the TCP/IP stack. No backwards compatibility and no better off than IPv6.

          IPv6 boosters are fond of this talking point, but "no backward compatibility" is a gross exaggeration, or to be precise it is a false dichotomy, when in fact the ability to preserve front end interfaces that are familiar to users and administrators is a form of backward compatibility. But that certainly would not be the only form of backward compabitility offered by an extended IPv4 stack.

          • The backward compatibility breakage happens right @ the IP header, where the sizes of the source and destination addresses are defined. So an application that looks for a source address @ bit 192 would now have to start looking @ bit 193. Similarly, if the address sizes were changed to even 33 bits, similar changes would happen @ the header, albeit different in magnitude, and every router in the world would still have to be reconfigured/redesigned, and every IP app would still have to be re-written. Fron

            • Wah wah, we can't figure out where to put some more bits. There must be just no way. Right.

              • You can. Just that every system that deals w/ it has to know that there are more than just 32 bits to the addresses. And once they're all going to be retrained, it's no different from the sort of effort that IPv6 is going through. In fact, by now, IPv6 has the most widespread support of any standard except IPv4, and if anyone were to come up w/ something else, it would be way behind IPv6 as far as adaption goes.

                • Actually, you can pack extra bits into an IPv4 packet in such a way that a) valid packets using 32 bit addresses remain valid and b) packets with extra address bits are seen as invalid by unaware network drivers. Therefore "they" are *not* all going need to be retrained, only thoes that want to access a wider address range. So how much smoother that would have been rollout wise? We would already be there by now if a sensible approach like this had been adopted instead of the throw out the baby with the bath

                  • Where do you specify that? The IPv4 header ends w/ the destination address, and then the payload starts - the type of message, code, checksum, identifier, sequence number and then actual data. Before source address, there was version#, type of service, length, identification, flags & offsets, time to live, protocol and checksum. So where exactly do the extra address bits go? Oh, and remember, it will be needed for both source and destination.

                    Okay, let's say it was expanded to 40 bits, and we calle

                    • Nice straw man. You assumed that an some of the bits of an extended address could be interpreted as a valid address and nasty things would happen. But these nasty things will not happen if an IPv4+ packet with extended addresses is constructed to appear invalid to an unaware network driver. So basically you could have saved typing your last two paragraphs.

                      Your question of where to put the new addresses bits is constructive. The obsolete [ietf.org]stream id option seems like a reasonable candidate, providing additional

                    • I don't see why that's a straw man. An unaware network driver could just read what's in the source and destination addresses, and ignore the areas that have the extended addresses - particularly if it happens to fall within a deprecated area in the header. Which is why the new addresses created would have to be compatible w/ what currently exists, thereby capping the growth headroom mentioned.

                      Also, this proposal essentially means kicking the can down the road, requiring a future generation to have to de

                    • So the principle is this: two extended address bytes are tucked away in places that will not destroy the internet. Such packets are constructed to appear invalid to unaware applications. If a path exists between a source and a destination both supportting extended addresses then the source and destination can communicate in the extended address space. The new byte goes at the least significant end, not the most significant, so that routing databases do not need to change.

                      These ideas really boil down to the failure to understand the issue is not about IP headers, packet formats or finding clever places to put things.. It is about ADDRESSING.

                      If the address spaces between IP protocols overlap then nobody knows apriori what paths support which protocols. We can not know if host A communicating via IPv4 can also reach host B on IPvDP or what router along the path prevent host A from communicating with Host B . If the address spaces are kept separate this is not an issue. Ope

                    • I don't see why that's a straw man. An unaware network driver could just read what's in the source and destination addresses...

                      Not if it's an invalid packet according to an unaware network driver. For example, the checksum might be wrong. There are all kinds of things that can go wrong if an application tries to act on addresses contained in an invalid packet indeed. Delivery to the wrong protocol for example. What a mess that would make. An unintentional straw man is still a straw man, and you knocked that one down yet again.

                      Also, this proposal essentially means kicking the can down the road, requiring a future generation to have to deal w/ it.

                      Sure. We need time, and this buys time. If you are saying that is a bad thing, your argument is weak. We ki

                    • We can not know if host A communicating via IPv4 can also reach host B on IPvDP...

                      Yes we can. If the low order byte of host B's address is zero, they can communicate, otherwise A needs to upgrade in order to establish a direct connection with B.

                      ...or what router along the path prevent host A from communicating with Host B .

                      IPv6 has the same issue.

                      If the address spaces are kept separate this is not an issue. Operationally this is critical to facilitiate migration.

                      What? Your leap of logic escapes me.

                      You could solve the problem for peers only by giving all existing IPv4 hosts addresses on the new extension network...

                      As I already stated. Standard IPv4 addresses are extended with a byte of zero at the low order end.

                      but this does not address routers, requires everyone renumber anyway...

                      How do you conclude that renumbering is required?

                      and is therefore no better than IPv6.

                      You haven't proved that, especially not without filling in your logical holes above.

                      Operationally IPv6 massive address space is a huge win for operators and end users

                      Both those claims are firmly in the "hopefully, one day"

                    • Yes we can. If the low order byte of host B's address is zero, they can communicate, otherwise A needs to upgrade in order to establish a direct connection with B.

                      I want to send a message to host A from host B. Host A is on IPv4. Host B is NOT. Host B does NOT have an IPv4 address because ah ...well they ran out and running out has consequences.

                      How does host B know if host A will be able to receive host B's message?

                      IPv6 has the same issue.

                      IPv4 and IPv6 are separate networks, separate routing, separate addressing. There is no problem of partial reachability within an IP universe in a dual stack environment. Either you have IPv4 connectivity, IPv6 connectivity or both. IPv4 and IPv6 un

                    • Sure. We need time, and this buys time. If you are saying that is a bad thing, your argument is weak. We kicked the can down the road when we went from 8 to 16 bit microprocessors, and again when me moved to 32 bit. What would have happened if the industry had decided to start off with 64 bit processors, just to avoid "kicking the can down the road"?

                      Had the industry started w/ 64-bit CPUs and OSs, that would have been fantastic. Imagine Windows being a 64-bit OS when the Alpha was around - it would have flown. Similarly, nobody would ever have been going through 32-bit to 64-bit transitions. Given that Unix resource requirements were much higher, most of them became 64-bit ages before Windows did. But had we all started w/ that, we'd have avoided the 8 -> 16 -> 32 -> 64 transitions. We're doing it correctly here by going directly from 32-

                    • Had the industry started w/ 64-bit CPUs and OSs, that would have been fantastic.

                      OK, you sent the message loud and clear: you have no concept whatsoever of the advantages of pragmatism. Like a typical IPv6 booster, you live in a cloud where efficiency does not matter, compatibility does not matter, only forcing the wodl to accede to the brilliance of the great new white elephant matters.

                      Hint: if intel had tried to market a 64 bit microprocessor instead of an 8 bit, or indeed, 4 bit processor they would have been years late to market and nobody would know about them now, nor care.

                    • Yes we can. If the low order byte of host B's address is zero, they can communicate, otherwise A needs to upgrade in order to establish a direct connection with B.

                      I want to send a message to host A from host B. Host A is on IPv4. Host B is NOT. Host B does NOT have an IPv4 address because ah ...well they ran out and running out has consequences.

                      How does host B know if host A will be able to receive host B's message?

                      Simple: if host A does not understand 5 byte IPv4+, it cannot establish a direct connection with host B. Host A should upgrade if it wants to connect directly to host B. Meanwhile, host B, with a 5 byte address, can connect directly to any IPv4+ enable

                    • How does host B know if host A will be able to receive host B's message?

                      Simple: if host A does not understand 5 byte IPv4+, it cannot establish a direct connection with host B. Host A should upgrade if it wants to connect directly to host B. Meanwhile, host B, with a 5 byte address, can connect directly to any IPv4+ enabled host whether the other host has a four or five byte address.

                      The question remains unanswered. How can you tell whether Host A AND your specific path to Host A supports IPv4+? Do you just try it.. if request times out assume it does not have connectivity? This delay is not commercially viable. What if the host was down or routing changed thru a router without support for IPv4+..how do you know? How does it work?

                      To connect to an unaware IPv4 host, host B needs some help from a NAT. This is where having the fifth byte on the low order end is really helpful: the NAT does not need to be stateful and does not need to delve into protocols. It just needs to manage its pool of dynamic IPs as dynamic IP shemes already do.

                      It most certainly needs to keep state... 1 real IP shared by a bunch of fake (IPv4+) IPs requires state to manage the 1:many association on the real IP.

                    • How can you tell whether Host A AND your specific path to Host A supports IPv4+? Do you just try it.. if request times out assume it does not have connectivity?

                      That is how any connection to the internet works.

                      This delay is not commercially viable.

                      Only if you assume that a host with a 5 byte address tries to make all its connections directly before falling back NAT. But there is no requirement to do that. A 5 byte host can always use its ISP's nat, except when it discovers another 5 byte host via some out of band mechanism. For example, two users may be interested in establishing a secure connection for conversation or telephony, in which case they can well afford to take a few seconds to establish the

                    • OK, think about this. Clearly, IPv4+ will work just as well as plain IPv4 if you have a 4 byte address, whether that is static, or like the vast majority of connections today, dynamically allocated from a pool owned by the ISP. Now in addition you have the option of giving 5 byte addresses to up to 256 computers in your house or business or village sitting behind your four byte IP. These will all act just as if they had a four byte net-local IP, but in addition they all have globally routable addresses for

                    • Only if you assume that a host with a 5 byte address tries to make all its connections directly before falling back NAT. But there is no requirement to do that. A 5 byte host can always use its ISP's nat, except when it discovers another 5 byte host via some out of band mechanism. For example, two users may be interested in establishing a secure connection for conversation or telephony, in which case they can well afford to take a few seconds to establish their route.

                      IPv6 uses naming system and standardized default host policy to avoid all of this guesswork. Saying if you don't use IPv4+ ("always use its ISP's nat") then its not a problem is rather telling. "out of band" is punting to a magic unicorn that in many cases does not exist.

                      Adding delay and unpredictability to the current system is not going to fly with content. Whatever we transition to needs to be at least as good as IPv4 if we expect content to be a driver for adoption.

                      Your IPv4+ universe is the same empty cliff DISCONNECTED from the IPv4 universe.

                      Completely wrong. A 5 byte host is no more disconnected from the internet than an IPv6 host is today. See 6to4

                      You can bridge them using a number

                    • OK, think about this. Clearly, IPv4+ will work just as well as plain IPv4 if you have a 4 byte address, whether that is static, or like the vast majority of connections today, dynamically allocated from a pool owned by the ISP. Now in addition you have the option of giving 5 byte addresses to up to 256 computers in your house or business or village sitting behind your four byte IP. These will all act just as if they had a four byte net-local IP, but in addition they all have globally routable addresses for whatever segment of the internet has also adopted 5 byte addresses. At least that is something, don't you agree? Or don't you?

                      I think that would be really cool to have 5 bytes instead of four so we call get an extra 256 hosts per address.

                      Unfortunatly while cool the problem is the world is running out of IPv4 addresses. This means there will be no more 4-byte IPv4 addresses left under which an extra 256 computers could be made avaliable. The IANA free pool and APNIC are now mostly deserts and everyone else except afrinic will be deserts in a year or two.. Even the emergency reserved morsels to facilitiate IPv6 transition will ev

                    • ...there will be no more 4-byte IPv4 addresses left under which an extra 256 computers could be made avaliable.

                      Not a problem, addresses already recycle regularly. Nearly every time you relocate your home, for example. Or every time you connect if you subscribe for a dynamic address like most people.

                    • Ah, and the point is that an ISP could put multiple subscribers behind one four byte address. And it would be better than today's NAT, which is limited by available port addresses and is really a nasty, nasty kludge. And 5 byte address owners can establish direct connections with each other.

                    • Ah, and the point is that an ISP could put multiple subscribers behind one four byte address. And it would be better than today's NAT, which is limited by available port addresses and is really a nasty, nasty kludge. And 5 byte address owners can establish direct connections with each other.

                      We're going to spin new ASICS, patch all network, naming, application stacks, databases and backends all to accept an extra byte..essentially the same work needed to deploy IPv6 then at the end of all that we still have NATs and severe addressing problems?

                      Say you wanted to be an ISP and picked up a shiney new 4-byte ASN with your name on it. What would you expect to be able to route to your customers after all IPv4 addresses are long gone?

              • Re: (Score:2)

                by jbolden ( 176878 )

                It is not just extra bits, the entire routing / switching strategy changes. IPv6 has no layer 2 i.e. switching is based on IP not mac addresses. Also routing doesn't use routing tables.

                If it were just packing extra bits, it would be easy enough to layer IPv6 on top of IPv4 and in fact that is exactly what IPv4 -> IPv6 conversion devices do.

    • Mocking standards? (Score:5, Funny)

      by DragonWriter ( 970822 ) on Monday March 26, 2012 @07:09PM (#39479635)

      Based on my own company checks for readiness I assume the big hold up feature parody with IP4 and IP6 security software and equipment.

      "feature parody"?

    • time to move off of norton then

    • I know that FreeBSD is now complete w/ IPv6 support, to the point of supporting IPv6-only configurations, but what's the level of IPv6 support in OpenBSD? It would seem to me that if a router had OpenBSD on it and managed IPv6 traffic just like it could IPv4, a great deal of those problems would be solved - especially the ones dealing w/ the exploitation of security holes. Or are there finer details to these security issues that I'm missing?

      • Re: (Score:2)

        by jbolden ( 176878 )

        Yes there are finer details. When it actually comes to things like router and firewall code lots has to change.

        For example there is no more NAT, so security layers provided by proxying addresses have to be added directly.
        There are no more routing tables, so the layout of equipment should be different.
        There is no more layer 2.
        etc...

        For companies that laid out a complex network in the 1990s they have to do something like "port the code" over to IPv6 based solution.

        • Re: (Score:2)

          by dodobh ( 65811 )

          Routing tables and layer 2 still exist. It's just a differently sized header, and protocol version.

  • Networkworld confirms it! (Score:1)

    by Anonymous Coward

    i mean we all are just waiting on akamai, because without akamai
    nobody could run dns ... or not.

    • Re: (Score:3)

      by Spad ( 470073 )

      Akamai are big. Really big. Having them offer IPv6 services to their customers is a big step forward in terms of making IPv6 adoption practical.

    • i mean we all are just waiting on akamai

      Lets just say if you run TCPview (netstat on steroids) you'll find you have a lot
      of a184-84-209-18.deploy.akamaitechnologies.com's. The prefix will change but
      a lot of what you get (Browser wise) is through .deploy.akamaitechnologies.com

  • Their website has a "Net Usage Indices" part with a combo. They only have a click listener so changing the value with the keyboard doesn't update.

    If they can't get simple HTML/Javascript right, how can I trust them to get anything more complex right?

    • Maybe because they are in the bussines of content delivery, not content creation, so the inhability to make a simple HTML/Javascript site is not really relevant.

    • I have not looked, but I guess they have an onChange listener, and those are not activated by keyboard changes. If you want to complain about that, write a mail to w3c because they explicit said that this was the way it should be.

      • Looks like they attached a change listener via jQuery 1.7 with a method that's been deprecated since 1.4. The change event is activated by any change, but only after the element loses focus. Its an implementation that looks like it works at first glance, but fails when interacted with in a manor they did not consider.

  • cloudflare (Score:1)

    by Anonymous Coward

    cloudflare is already doinf that for free : http://blog.cloudflare.com/introducing-cloudflares-automatic-ipv6-gatewa [cloudflare.com]

  • I want qwest/century link to get moving on IPv6. They WERE moving to it before century link merged with them. Now, they are going backwards. We need large ISPs to move ASAP to IPv6 to free up IPv4s.

    • The move to IPv6 wouldn't - and shouldn't - free up any IPv4s. IPv4s (I'm talking about routable IPv4s here) will still be needed and used to support dual stack. What would change is that for every node that requires external connections and offers IP based services, IPv6 would be used, while IPv4s would only be used for things like websites. In fact, think of IPv4s as mirrors of IPv6 websites for those who can't access IPv6. Or, in other words, use IPv4 only for services that absolutely must be offered

      • The dual stack SHOULD only exist for a year or two. After that, the ISPs then drops the dual and only presents IPv6 first to all businesses, and then in another 6 months to all clients. The issue is that we need to have 1-2 years to shake it out. And it will take that long for ppl to realize what changes they need to do.

        To make all this happen, the large hosting services and major ISPs should come to agreement on this. This is more true for the major ISPs in markets where they compete. For me, that is com

        • Re: (Score:2)

          by jbolden ( 176878 )

          The internet is global. There isn't going to be a coordinated switch. Rather it is going to go:

          a) Carriers go dual stack
          b) Cell / Home / Small business on IPv6 with IPv6 -> IPv4 gateways. That's one transition.
          c) MId / large business go internally dual stack while having IPv6 outward facing.

          Then probably in a decade or more.

          a) Most carriers stop offering IPv4
          b) The gateways get crappier and worse and finally become an extra cost feature.
          c) Mid / large business have only very small isolated IPv4

      • Re: (Score:2)

        by jbolden ( 176878 )

        Actually it will free up IPv4s because of pooling.

        Lets say I provide internet connections to 1m people via IPv4. That is 1m IPv4 addresses, dynamically allocated but they are held for a day plus on average. Now I start pooling so that an IPv4 address is surrendered after 5 minutes of being idle. I might be able to drop down to 200k addresses freeing up 800k. That is the in fact exactly the incentive for the carriers to move home / small business to IPv6 with IPv6 -> IPv4 pooling.

  • So when will Slashdot be on IPv6? (Score:4, Insightful)

    by Skapare ( 16644 ) on Tuesday March 27, 2012 @02:29AM (#39481855) Homepage
    So when will Slashdot be on IPv6? Inquiring minds and nefarious hackers want to know.

Slashdot Top Deals

On the eighth day, God created FORTRAN.

Close