Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
The Internet Technology

IPv6 Traffic Remains Minuscule 406

judgecorp writes "Even though we are running out of IPv4 addresses, IPv6 traffic is still not taking off. In fact it is less than one percent and falling, according to a report from Arbor Networks."
This discussion has been archived. No new comments can be posted.

IPv6 Traffic Remains Minuscule

Comments Filter:
  • Re:Just a thought (Score:4, Informative)

    by maswan ( 106561 ) <(wm.wm.nawsam) (ta) (2todhsals)> on Wednesday April 20, 2011 @11:25AM (#35881178) Homepage

    There is no such requirement!

    One of the many possibilities for choosing the local part of the network is using the MAC address of the network interface. There are several other choices available, like choosing one manually or generating a random one (you can in fact generate random ones rather frequently, see "privacy extensions").

    Depending on your OS vendor, one of these will be the default behavior, but you don't have to do it that way if you don't like it.

  • Re:what is... (Score:2, Informative)

    by jd ( 1658 ) <imipak@yahoGINSBERGo.com minus poet> on Wednesday April 20, 2011 @11:33AM (#35881344) Homepage Journal

    The world actually ended last night at around 8pm. Skynet, however, has opted to put us in the Matrix as their robot division was bought out by General Motors.

  • by jd ( 1658 ) <imipak@yahoGINSBERGo.com minus poet> on Wednesday April 20, 2011 @11:35AM (#35881370) Homepage Journal

    It does work, as evidenced by the fact that people are already doing exactly that.

  • Re:Digital TV (Score:5, Informative)

    by AVee ( 557523 ) <slashdot&avee,org> on Wednesday April 20, 2011 @12:08PM (#35881816) Homepage
    Enforcement (or at least serious stimulation) by the Government may well exactly what is required to get IPv6 off the ground. The main problem (on the consumer level at least) is the definitely the lack of equipment. Making it illegal to sell modem/routers which lack IPv6 support will fix that in no time making it way easier for providers to roll out dual-stack to there customers.
    Providers could use DHCPv6 on their networks and simply issue an IPv6 range to anyone who's router requests it, no one will notice the difference. But currently that's just pointless because nobody will have an IPv6 capable modem, not even when they bought it yesterday.

    I'm getting native dual-stack on my VDSL line at home, along with 7000 other customers. But they had to push their modem manufacturer (AVM) to get it properly implemented. Their list of supported modems [xs4all.nl] is depressingly short, it contains 3 AVM models which basically use the same firmware, one Draytek modem and two Cisco which aren't really what I'd call 'consumer grade'. But it works just fine, I'm pretty certain a customer who doesn't care wouldn't notice the difference.
  • by jd ( 1658 ) <imipak@yahoGINSBERGo.com minus poet> on Wednesday April 20, 2011 @02:32PM (#35883790) Homepage Journal

    It depends some on the type of server involved. For example, with a webserver and a non-encrypted connection, the URI is contained in the request, so the DNS entry can point to a proxy server (such as Squid). The proxy handles the gateway onto IPv6 transparently, giving the illusion that the web request went directly to the destination. The fact that DNS didn't resolve to the webserver would never be visible to the user.

    For other types of connection, you can only pull that specific trick if you are prepared to hide portions of the Internet. It also requires dynamic DNS and some of the trickery used for reverse NAT. A request comes in for an A record but only an AAAA record exists. The proxy has a pool of IPv4 addresses it can use and a map that associates an IPv4 address to an IPv6 address - your standard address-based (as opposed to port-based) DNAT but across protocols. The proxy creates a DDNS entry for the IPv6 server using an IPv4 address that's unique for that server. The proxy now knows exactly what IPv6 server to forward the requests to, so doesn't need to do any kind of packet inspection.

    In this second case, all you're doing is ripping the payload out of one container and shoving it into an equal-sized container of the other protocol. TCP and UDP payloads don't change at all between containers and hardly any of the container information will be of any interest on the other side of the gateway.

    This does limit you, though. If an ISP were to install a proxy of this kind, it would be limited to 16,711,680 simultaneous IPv4/IPv6 gateways if it wanted to avoid clashes with the existing IPv4 backbone. That's not the same as 16 million users, since 16 million users all accessing YouTube would still equal one gateway. It would have to be 16 million distinct IPv6 destinations and all at the same time (since an unused gateway can be closed and the DNS entry recycled).

    Such proxies exist. In fact, the Naval Research Laboratory once wrote a really neat library back in the mid 90s that made it a cinch to not only write them but make them bi-directional (ie: an IPv6-only machine could access an IPv4-only machine behind such a proxy as easily the other way round). They're also not hard to write, since all the mechanisms you need are widely deployed.

    A third solution does exist. IPv6 supports a format for embedded IPv4 addresses. (::127.0.0.1, for example, is perfectly legit IPv6.) So long as the IPv6 destination has a unique embedded IPv4 address as a valid record, a DNS server can return the embedded portion as an A record that uniquely identifies that machine in IPv4-space. Then all you need is payload copying between containers and no fancy address translation or DDNS support. This requires that only a fixed subset of all IPv6 machines are reachable, as opposed to the second solution which merely requires that a subset of IPv6 machines that is fixed for any given moment in time are reachable, so it's less flexible but can be installed as a module directly into a customer's router.

    IPv6 proponents haven't been keen on these kinds of solution because cross-protocol NAT can only support those features that exist on both protocols, whereas the preferred dual-stack solution gives you the best of both worlds. I've always found that argument to be dubious, however, because it was obvious to me that transparent migration would be less likely to meet resistance since there would be zero impact on end-users. Now, fifteen years on, I'm more convinced than ever that the 6Bone working group made a disastrous mistake in pressing for dual-stack rather than transparent solutions. Sure, if they'd just handed me control I'd have botched it up somewhere else and probably far worse. Nonetheless, I'm torn between gloating evilly and screaming in disgust that an astonishingly stupid attempt at power-play has held back IPv6 progress for one and a half friggin' decades.

The one day you'd sell your soul for something, souls are a glut.

Working...