Slashdot Mirror
IPv6-Only Is Becoming Viable
An anonymous reader writes "With the success of world
IPv6 day in 2011, there is a lot of speculation
about IPv6 in 2012. But simply turning on IPv6 does not
make the problems of IPv4
exhaustion go away. It is only when services are usable
with IPv6-only that the internet can clip the ties to the IPv4 boat
anchor. That said, FreeBSD, Windows,
and Android
are working on IPv6-only capabilities. There are multiple
accounts of IPv6-only
network
deployments. From those, we we now know that
IPv6-only is viable in mobile, where over 80% (of
a sampling of the top 200 apps) work well with
IPv6-only. Mobile especially needs IPv6, since their are only
4 billion IPv4 address and approaching 50
billion mobile devices in the next 8 years. Ironically,
the Android test data shows that the apps most likely to fail are
peer-to-peer, like Skype.
Traversing NAT and relying on broken IPv4 is built into their method
of operating. P2P communications was supposed to be one of the
key improvements in IPv6."
Bullshit sir, I run Linux on my IPv6 connection.
Are you trolling, or horribly confused between domain names and IP addresses?
There's no -1 for "I don't get it."
Right. That was why .xxx was introduced. It opened up so many free "names" as you call them, on the "regular" internet. All those porn names are free for you to use now.
Really, if that was the issue then just using 26 letters in a name and 20 char names gives 26^20 names. That's more than could possibly be needed. So ask yourself, Einstein, what's wrong with your point?
Of course Linux is not "working on" IPv6 implementation. IPv6 already works on Linux AS IS and has been for a number of years now.. Lots of places alrady have IPv6-only for internal networks. IPv4 is only for legacy apps, like phones.
So move along troll, move along.
Is it dual stack? FreeBSD developers have actually set it up in recent releases so you can compile with ONLY IPV6 (INET6), IPV4 (INET), or SCTP only. Then they came up with a bunch of tests to see how IPV6 only would work on the Internet and then they checked for compliance. It's rather amazing what they've accomplished so far and most of it within days of last year's world IPV6 day.
I expect a recent linux kernel to do well with IPV6. I'm not questioning that. Just wondered if it's still dual stack dependent and how much testing has happened with userland bits. Since it's a distro problem more than just the kernel. In FreeBSD, they have to make sure all the userland parts work too. The biggest missing piece is DHCPv6 in FreeBSD that I know of.
MidnightBSD: The BSD for Everyone
The problem under discussion is a shortage of IPv4 addresses, not a shortage of domain names. A device needs an IP address to send and receive anything via TCP/IP, as on the Internet. Domain names are an optional convenience.
Which is going to be really important as it can be really hard to verify that things are working on a dual stack system. I remember the last time I tried it I never could figure out if it was working as it should be or just falling back to IPv4 and quite honestly I had neither the time nor the inclination to dig too deeply into it.
IPv6-only. Linux has worked on IPv6 for a long time, and in general, will work on IPv6-only, but some specific tools and applications present in some Linux distributions will not.
The point here is that FreeBSD functions completely without IPv4, and not just over the internet, but internally as well. It's actually a much tougher task with Linux as Linus only controls the kernel, he has to convince other projects to go IPv6 only as well.
Given the fantastic growth in the number of Internet-enabled mobile devices, and that the infrastructure for such devices is still in rapid development, it makes sense that this is where you'd see IPv6 completely implemented first.
Until IPv6 is offer by a single ISP or Telco then it is the stuff of myths. Nice to read about but not part of the world I live in.
I get to test software on the Internet. In the grand scheme of things there are few servers out there talking IPv6 at the moment. There are relatively few Web servers talking IPv6, and there are relatively few DNS servers talking IPv6. If I configure a caching DNS server to be IPv6 only I can only talk to a few things today. Even if the DNS server is configured to talk IPv4 but I query for names on IPv6 (AAAA records) there are few to find. Many DNS servers don't even handle AAAA requests properly. A lot of infrastructure is yet to be deployed to make IPv6-only a viable way to access the Internet.
Those millions of mobile devices talking IPv6 today can only do that going through NAT64 gateways (read that as NAT 6 - 4, as in allowing IPv6 to access IPv4). Yes, having the devices that can talk IPv6 is part of the solution. Now the servers need to be there.
I suppose you could call the large number of IPv6 devices the "chicken". Now the chicken needs to lay the egg.
50 billion mobile devices? How much of this will end up as landfill? Does everybody REALLY need seven mobile devices?
Also, I'd feel a lot better about IPv6 if there weren't quite so many RFCs associated with it. The more complex a standard is, the more room there is for security holes, bugs, and non-conforming implementations... Is the second system effect going to bite us in the ass really hard?
Well, maybe we WILL need seven devices, just to load the new stack once..
Yes, but each command has been duplicated: ping, ping6; tracert, tracert6; etc. It doesn't seem particularly elegant to me. Why not just modify ping to accept both IPv4 and IPv6 addresses?
When our name is on the back of your car, we're behind you all the way!
Because Ping is almost 30 years old and changing it that substantially would break functionality in a huge number of OSes. Not to mention the fact that as long as IPv4 is in common use it's going to be damn confusing figuring out when it's safe to use ping in IPv4 versus IPv6.
In a few years time when we're hopefully all using IPv6 then it might be reasonable to switch it.
One thing that is not mentionned here is that the 4G specs actually mandate IPv6 and deprecate IPv4 support - something that should really push IPv6 adoption forward, especially with providers that offer both cell phone and traditionnal internet connectivity...
Good thing too. Getting those suckers in would have been difficult otherwise. With IPs running out in Europe this year, we are really starting to feel the pressure now...
Semantics is the gravity of abstraction
Though this discussion has focused purely on web access over the Internet, as many people mistakenly believe they're the same thing, there's still work to be done for enterprise and service provider networks to operate on pure IPv6. For example, with IPv6, there isn't really provider independent address space. So, when you get all your address space from your ISP, how do you dual-home to different ISPs? ISPs are not going to accept your advertisements of another ISPs address block like they would with IPv4. Why? Since the IPv6 address space is so large, they've already decided to limit the scale of the global BGP address table. So what? Well, now your hosts have to have multiple IP addresses. No big deal, IPv6 hosts already would already have multiple addresses assigned anyway for other purposes. The problem is now your hosts have to have the intelligence to decide which address to use. You could get around this by using only one ISPs addresses internally and NATing to the others for traffic in and out of the other ISPs link, but then you get back into what you were doing before with IPv4. Additionally, if you decide you no longer like that ISP, you have to readdress all your hosts. This is only one problem in a long list of many semi-larger (LDP can't signal over IPv6, etc.) and smaller, probably ignored problems (BGP router IDs currently only supported a 32bit number and are usually the IPv4 address used to initiate the session, etc.)
Like just about everything done in perl.perl-considered-harmful
605413? Yes, it's a prime.
Those ain't commands but system programs.
pingm, tracert, cp, mv and so on are p r o g r a m s and not commands.
Commands are shell (like Bash, what is one program as well) internal functions.
Do not mistake program and command as same thing.
Is it now? How hard is it to remove the IPv4 assignments from your network interfaces and lo? Oh, that was pretty easy. Took seconds.
I'm happy for all the BSD guys who are doing the IPv6-only dance of joy but it's a political move rather than a useful one to remove the IPv4 stack from the kernel on anything but extremely limited devices. You don't actually gain anything by removing it on a desktop, laptop, server, or most consumer embedded devices.
At this point, it's a lot like buying an electric car when your power comes from a coal plant. It may make you feel better about yourself but nobody actually gains anything.
Violence is like duct tape. If it doesn't solve the problem, you didn't use enough.
Even that Linus controls only the whole Linux operating system, it is still the Operating System job to offer network protocols to every program. The programs can itself then offer own protocols (like http, ftp or ssh).
Operating System offers Transport and Network layer protocols to Session, Presentation and Application layers.
I would hold that a binary executable would be quite modifiable without changing the output from a given standard.
If that was the case, how could I expect to create even a basic ASCII text editor?
Though admittedly, it would explain a lot about Microsoft Word.
Now deciding what to do in an IPv4/IPv6 situation regarding Ping and other such protocols would be important, but wait, wait, didn't they do that when writing IPv6?
Tell me I'm not hallucinating.
ping and ping6 speak ICMP and ICMP6 respectively. Those are not the same protocol, and they are both lower-level than IP, not higher, so they are real differences in the way the programs work. Their UI looks the same, but they're not very alike under the hood. If you're going to combine IP-ping and IPv6-ping you might as well throw AppleTalk-ping in there -- just because they have similar names doesn't mean they should all be in the same tool.
traceroute is at least IP-layer, so while it has to handle both stacks it doesn't do particularly different things. And because of that you'll find that the traceroute implementations that are still being maintained support both stacks -- traceroute6 is often just a link to traceroute, or a link that prepend "-6" to your arguments.
Criminal Hackers all over the world are working hard to come up with lots of zero day exploits for IPv6. When it finally goes live, they'll have plenty of hacks to bring it down in the first hour.
I'm surprised at the amount of need for IPv6 upgrades at the application level. Really I would hope more OSes would allow IPv6 only with an internal IPv4 fake NAT approach to translate IPv6 information (local and remote targets) to fake internal IPv4 addresses. Remote targets would also need some form of IPv4 to IPv6 resolution. Perhaps add a notification from the OS that the application in question is not IPv6 capable and running in a compatibility mode with degraded performance.
And yes, I know part of the reason for IPv6 is to eliminate NAT, but I am just considering all the legacy application issues sure to arise without strong OS level support for bassackwards compatibility. Application level support should mostly be confined to various master server schemes, like IM clients, where the master server gives peers IPv4 addresses from clients for features like video chat. Still, some kind of DNS-like system for servers to aid in resolving IPv4 addresses to IPv6 would act as a patch during migration for legacy programs.
ICMP runs on top of IP so I'd say it is a higher level protocol.
You're kidding right? There was a noticeable degradation in V4 performance for the exact period described by the V6 test.
Hurricane Electric had some links carrying v4 traffic that went completely down; at least of their peers severed the connection in the middle of the test.
If this had been an attack, people would be getting. This crap isn't finished enough to "test" and screw up the (overwhelmingly huge) part of the net that *actually works*.
This isn't IPv6-only in any meaningful sense of the term. All you've done is move the dual part of the stack from the mobile device to the operator. In fact since the *overwhelming* majority of servers are reachable by IPv4 only, the NAT64 will be used for almost everything. And since the IPv4 address the device would get in a dual stack setup would almost be from a NAT as well, you haven't actually changed IPv4 address usage in any significant way.
This is one of those necessary steps that has to be taken on the road to an IPv6-only world and I am glad to see it happen, but it is one that offers fairly little direct benefit. And the really big problems remain: (1) The millions of home routers that aren't IPv6-capable and the failure of the vast majority of ISPs to offer IPv6 connectivity to their customers.
ping/ping6 are network diagnosis tools. You want to be able to check IPv4 and IPv6 connectivity. explicitely. I agree that this could have been done with a single command with -4 and -6 options, though.
I don't even know how to replay to your poorly worded post.
It's the complete utility that's the problem, not just the output. It has to be able to handle IPv6 and be able to do something useful with it. Putting them together in one utility makes very little sense as the only people likely to still be using IPv4 in 10 years time are people in an enterprise environment and they'll likely to adding the IPv4 version to their install images. Well them and retrogamers, but they'd know how to install the package and use it if they really needed it anyways.
You don't write protocols based upon how they will or won't reuse existing utilities, doing that is extremely short sighted and I'd be shocked if they took this into consideration outside of the migration provisions. Ultimately it's up to the person who is typing the command to know what they're wanting, you're not going to create a program that knows that reliably. If you don't believe me, boot up a copy of Windows and see how many times it makes the completely wrong decision about what you're wanting.
You seem to be confused. Linux is a kernel, no more no less. A Linux distro is a Linux kernel with a 3rd party userland. The kernel itself really has very little to do with what protocols are ultimately offered to the userland as those all have the option of loading kernel modules if need be.
Honestly, it's not that complicated. Those userland programs are why Linux can't yet be IPv6 only yet. I believe that most of them can handle it, but there are still IPv4 only utilties left.
how could I expect to create even a basic ASCII text editor?
Easily. But once you've created it, you're not allowed to change it or else everyone else using your basic ASCII text editor will be pissed off. I wonder how microsoft felt when they were going to change qbasic while edit.exe expected it to work the way it had for a decade.
I'm sure there are a half billion scripts out there that expect to see "64 bytes from foo.com (xx.xx.xx.xx): ..." and will shit themselves when it becomes "64 bytes from foo.com [xxxx:xx::xxxx]: ..."
There are different grades of IPv6-only. For example lots of computers that claim to work IPv6-only still have "localhost 127.0.0.1" active because some programs expect to see that. And there is also the question how much unused IPv4 code is in an OS its kernel even when IPv4 is not used at all. The definition above seemed to be more to mean that the apps where communicating over IPv6 so enough web resources should be available through IPv6 or through translating proxies, and the user land programs should be able to deal with IPv6 addresses.
Of course! einstein.xxx!
...
Oh god!
At this point, it's a lot like buying an electric car when your power comes from a coal plant. It may make you feel better about yourself but nobody actually gains anything.
Well, with an electric car, you move the emissions to the industrial area that hosts your local coal plant, and so hopefully make the neighborhoods you drive in healthier places to live. Similarly, the uh, network ecosystem of the, uh kernel environment... Ugh. This is the one time when a car metaphor won't work!
Yes, but each command has been duplicated: ping, ping6; tracert, tracert6; etc. It doesn't seem particularly elegant to me. Why not just modify ping to accept both IPv4 and IPv6 addresses?
There is no justification for not fixing linux ping. Microsoft has it right. Traceroute works properly. What broke when traceroute was fixed to support both versions? There is no excuse for not fixing ping.
Now that virtually all host applications had been modified to support ipv4 and ipv6 transparently based on DNS I don't want to hear this total nonsense fixing ping will cause breakage. Bullshit.
The whole point in the transition is that you do not know ahead of time whether a host is IPv4 or IPv6. By not fixing ping and something does does not work you 'ping' it and the result you get is totally out of step with the way the rest of the operating system and your apps work.
Android is Linux.
Dilbert RSS feed
I was trying to remember which tools I'd read about lacking proper IPv6 support, but I hadn't remembered Perl. That's a real problem.
Another reason I need to get on with learning Python.
====
ifconfig lo down
ifconfig eth0 del YOUR_IP
killall dhclient
====
Hey, that was easy!
Because Ping is almost 30 years old and changing it that substantially would break functionality in a huge number of OSes. Not to mention the fact that as long as IPv4 is in common use it's going to be damn confusing figuring out when it's safe to use ping in IPv4 versus IPv6.
You have things totally backwards. The operating system figures out whether a host should be reached via ipv6 vs ipv4 based on your systems IPv6 connectivity and DNS. You can't know it in advance.
If I browse to www.slashdot.org and it has an AAAA record and my computer has IPv6 I get to slashdot via IPv6. Having ping being the only utility left on the fricking operating system that does not work this way is more broken than any nastalga.
Traceroute is 30 years old too and it works just fine with both protocols enabled at the same time.
Total nonsense. traceroute
Sure it will. It's like tossing your ratty old spare tire out because you have four spankin new ones on the wheels. You lose a security blanket you might need for the sake of not having anything ugly and old around.
Violence is like duct tape. If it doesn't solve the problem, you didn't use enough.
Not really, I could have done that on FreeBSD years ago. You do realize that the loopback interface isn't necessarily IPv6 compliant, which is the whole point of this. They made it so that you could compile the kernel and the userland all without the use of IPv4.
But, then again, why bother with facts when you can post a smart ass comment.
I'm thinking IPv4 will be around for a long time to come, for those of us on hardline internet. It's easier to block a range of IP addresses than it is to manually insert random IPv6 addresses. The US government will want to control access to the internet, thus, IPv4 is a Good Thing from the viewpoint of the US government and their corporate sponsors.
Understanding the scope of the problem is the first step on the path to true panic.
It is ping and traceroute that are the odd ducks. Most of the unix commands have a -4/-6 switch: telnet, ssh, mtr and so on.
It is quite annoying actually. I can ssh any domain and it will automatically work no matter if that domain has a A or AAAA record. But to ping the same domain I suddenly need to know.
This example is quite obvious but it might not be in a few years when IPv6 only sites are common:
# this fails
baldur@pkunk:~$ ping -c1 ipv6.google.com
ping: unknown host ipv6.google.com
# this works
baldur@pkunk:~$ ping6 -c1 ipv6.google.com
PING ipv6.google.com(fra07s07-in-x67.1e100.net) 56 data bytes
64 bytes from fra07s07-in-x67.1e100.net: icmp_seq=1 ttl=49 time=43.4 ms
--- ipv6.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 43.449/43.449/43.449/0.000 ms
# curl automatically does the right thing: ...
baldur@pkunk:~$ curl -v http://ipv6.google.com/
* About to connect() to ipv6.google.com port 80 (#0)
* Trying 2a00:1450:4001:c01::67... connected
* Connected to ipv6.google.com (2a00:1450:4001:c01::67) port 80 (#0)
I was recently in attendance in a chat room where I noticed several people's connections info seemed to include IPV6 addresses (hexadecimal separated by ':' ) When I asked one of them how they were liking IPV6, they responded that they did not even know they were using IPV6, that they were using their iPhone to join the chat room.
It is ping and traceroute that are the odd ducks. Most of the unix commands have a -4/-6 switch: telnet, ssh, mtr and so on.
It is quite annoying actually. I can ssh any domain and it will automatically work no matter if that domain has a A or AAAA record. But to ping the same domain I suddenly need to know.
It depends on what OS you're running. While linux [and my mac] has ping6 and traceroute6, Solaris 10 does not use separate version of ping/traceroute. So if you have a dual stack network, when it resolves the domain name, if it gets an IPv6 address, it'll ping that address. If it doesn't have an ipv6 interface, it's smart enough to know, and will ping the ipv4 address. Of course if you try to ping an IPv6-only target [ie ipv6.google.com] on a host that only has ipv4, it will say it's an unknown host. It's quite nice. Of course, there's lots of other annoyances with Solaris's ping, like the fact that you can't give a count of how many times to ping unless you also give a packet size. :^/
### Host with dual-stack network
ender@host1:~$ host www.fearthepenguin.net
www.fearthepenguin.net has address 173.236.150.4
www.fearthepenguin.net has IPv6 address 2607:f298:2:122::49f:d613
ender@host1:~$ ping -s www.fearthepenguin.net 56 2
PING www.fearthepenguin.net: 56 data bytes
64 bytes from fearthepenguin.net (2607:f298:2:122::49f:d613): icmp_seq=0. time=37.2 ms
64 bytes from fearthepenguin.net (2607:f298:2:122::49f:d613): icmp_seq=1. time=35.7 ms
----www.fearthepenguin.net PING Statistics----
2 packets transmitted, 2 packets received, 0% packet loss
round-trip (ms) min/avg/max/stddev = 35.7/36.4/37.2/1.1
### Host with IPv4 network only
ender@host2:~$ host www.fearthepenguin.net
www.fearthepenguin.net has address 173.236.150.4
www.fearthepenguin.net has IPv6 address 2607:f298:2:122::49f:d613
ender@host2:~$ ping -s www.fearthepenguin.net 56 2
PING www.fearthepenguin.net: 56 data bytes
64 bytes from apache2-argon.lusaka.dreamhost.com (173.236.150.4): icmp_seq=0. time=37.2 ms
64 bytes from apache2-argon.lusaka.dreamhost.com (173.236.150.4): icmp_seq=1. time=36.8 ms
----www.fearthepenguin.net PING Statistics----
2 packets transmitted, 2 packets received, 0% packet loss
round-trip (ms) min/avg/max/stddev = 36.8/37.0/37.2/0.29
ender@host2:~$ ping -s ipv6.google.com 56 2
ping: unknown host ipv6.google.com
Nothing to see here
So Skype would be extending current service levels to ipv6-only...
traceroute is at least IP-layer, so while it has to handle both stacks it doesn't do particularly different things. And because of that you'll find that the traceroute implementations that are still being maintained support both stacks -- traceroute6 is often just a link to traceroute, or a link that prepend "-6" to your arguments.
LOL traceroute is just a bunch 'o ICMP pings with varying TTLs.
Way to totally misunderstand the post.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
http://xkcd.com/865/
LOL traceroute is just a bunch 'o ICMP pings with varying TTLs.
Umm. no. ICMP unicast L2 ping utilities measure single hop one to one TTL. While traceroute ICMP unicast works the same, default behavior in most multicast l2/l3 traceroute utilities measure one to many hops in-route TTL.
"Don't let fools fool you. They are the clever ones."
Or anyone else with an IPV4 only address?
Who's going to pay for the billions of IPv4 devices that need to be replaced in order to offer IPV6 only services to folks?
I say simply bolt another 8 octets onto existing IPv4 address space, and use the tried and true TCP/IP protocol suite.Backwards compatibility is good.
Call it IPv7...
For in politics, as in religion, it is equally absurd to aim at making proselytes by fire and sword. - Publius
Since it's unlikely you understand why you were down-modded into oblivion, I'll point out what was blazingly obvious to everyone else: The OP was referring to Linux, and the reference to removing IPv4 was implicitly also referring to Linux. As a result, your post is now rated exactly where it should be.
How could you even discover that /. existed?
I mean, confusing IPv4/IPv6 addresses with domain names.
Somebody from my ISP has told me, in so many words, that they have absolutely no intention of making IPv6 available to consumers until [!!!!] they run out of IPv4 addresses... which the fellow I spoke to insisted was still years away, and offered absolutely no timeline given for any actual switch. To top it all off, he said that they would not even be doing any sort of gradual transition when it does happen... that the switchover would be essentially instantaneous for everybody, and would be transparent for anybody using a currently patched version of their OS.
I hate my ISP... but there's only 3 to choose from where I live, and the other two each have problems of their own that I would be utterly unable to live with.
File under 'M' for 'Manic ranting'
errr...um... from what I understand, all of the low level protocol stack is in the kernel. the userland utils (iputils) and network applications make calls to the kernel. I don't even think libc gets involved here. if you want an ipv6 only system, just set the v4 ip to 0.0.0.0. it's not difficult.
If I browse to www.slashdot.org and it has an AAAA record and my computer has IPv6 I get to slashdot via IPv6. Having ping being the only utility left on the fricking operating system that does not work this way is more broken than any nastalga.
Except that TCP hasn't changed. TCP still rides inside IP packets (v4 or v6), and thus apps based off TCP should work this way[0].
Ping doesn't run off TCP, it runs off ICMP, and there are two different versions of this protocol: one for IPv4 and one for IPv6. ICMPv4 and ICMPv6 are nearly identical, but not quite (different mechanisms for checksum calculation, different error message enumeration). This protocol is ICMPv6.
Now that isn't to say that the developers of the current ping tools couldn't create some uber-ping tool that can handle both ICMPv4 and ICMPv6 packets. The formats are indeed similar -- most of the difference is in how checksums are calculated based on the packet (pseudo)headers and in the error message identifiers. For whatever reason, they decided to have independent versions per protocol.
The point being, it's not correct to compare ping to a web browser. Your web browser will use the same TCP packets regardless of if they're encapsulated within IPv4 or IPv6 packets. The DNS resolving is identical as well. Ping however has to use a different protocol depending on the version of IP being used, which changes the game slightly. And for whatever reasons, the developers who maintain these tools decided by-and-large to leave ping for IPv4 alone, and release a separate version for IPv6. You can certainly question the wisdom of that decision, but it certainly isn't as easy as the case of a web browser.
Yaz
-----
[0] - Of course, "should" doesn't mean "will". The biggest problem often being apps that have only ever reserved 32 bits for storing resolved addresses, or who don't know how to parse IPv6 formatted addresses entered directly.
But that's just dumb, and as a consumer who just wants to use IPV6 for what it offers me, I don't want to care that there are differences between ICMP and ICMPv6 (nor should I have to care).
Kid-proof tablet..
Umm. no. ICMP unicast L2 ping utilities measure single hop one to one TTL. While traceroute ICMP unicast works the same, default behavior in most multicast l2/l3 traceroute utilities measure one to many hops in-route TTL.
L2 multicast traceroutes...LOL...
Even MSFT's ping requires an option to pass ICMPv6 packets. This philosophy seems to be a thing.
Even MSFT's ping requires an option to pass ICMPv6 packets. This philosophy seems to be a thing.
bzzt...
C:\>ping www.ietf.org
Pinging www.ietf.org [2001:1890:123a::1:1e] from with 32 bytes of data:
Reply from 2001:1890:123a::1:1e: time=94ms
Reply from 2001:1890:123a::1:1e: time=87ms
Reply from 2001:1890:123a::1:1e: time=87ms
Reply from 2001:1890:123a::1:1e: time=84ms
Ping statistics for 2001:1890:123a::1:1e:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 84ms, Maximum = 94ms, Average = 88ms
C:\>
But that's just dumb, and as a consumer who just wants to use IPV6 for what it offers me, I don't want to care that there are differences between ICMP and ICMPv6 (nor should I have to care).
Fair enough, but while we're still in a dual-stack situation, you'd have to care enough to at least be able to tell a unified ping utility which protocol you want to use (even if it's just via a -4 or -6 switch). Otherwise, if a given domain name resolves to both IPv4 and IPv6 addresses, which should it pick? Perhaps if you're just using it to see if a host is up, you don't care -- but if you're trying to determine the connectivity of your network graph for a specific protocol set, it's important.
Ping isn't intended to be a novice utility. It's a serious piece of a network diagnostic toolkit. Your grandma isn't going to be running it, so the harm of having it separated into two utilities is minor; anyone serious about network diagnostics and administration isn't going to be phased by the fact that there are two commands, one per protocol.
Anyhow, you have every right to rant on about the separation of ping and ping6 into separate utilities if it's important to you; I simply wanted to point out that due to protocol differences, ping is not comparable to something that relies solely on TCP to function. TCP hasn't changed, and rides inside either IPv4 or IPv6 packets seamlessly.
Yaz
Seriously? Ping is a "serious piece of network diagnostic toolkit"?
Please allow me to rephrase: "Ping is the most basic part of a network diagnostic toolkit. If your grandmother learns one thing about IP networking and nothing else, it will be ping."
Kid-proof tablet..
"I expect a recent linux kernel to do well with IPV6. I'm not questioning that. "
Will stuff like netbooting (assuming PXE would work over v6) work? Will you be able to swap to a remote NFS device over v6 and have your root filesystem over v6? Stuff like that is still close to 100% v4-only today, but still something for all those thin desktop dists which still would be nice to have when its all v6.
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/l2trace.html
RFC1112 muticast space needs L2/L3 multicast mapping traceroute utilities which has been around longer than I would like to admit... grrr.. i'm old...
"Don't let fools fool you. They are the clever ones."
Exactly.
Basically, IPv6 is doomed because it is not compatible to IPv4-adresses.
Yeah, I know that dualstack exists, but the point is that if you cannot run IPv6 with a IPv4 address (filled up with zeros), it is useless.
Of course everytime someone points that out, there is a torrent of responses like this, all not understanding the problem:
What the IPv6-people just refuse to understand is that there is zero benefit for running IPv6 now.
Fair enough, but while we're still in a dual-stack situation, you'd have to care enough to at least be able to tell a unified ping utility which protocol you want to use (even if it's just via a -4 or -6 switch). Otherwise, if a given domain name resolves to both IPv4 and IPv6 addresses, which should it pick? Perhaps if you're just using it to see if a host is up, you don't care -- but if you're trying to determine the connectivity of your network graph for a specific protocol set, it's important.
I'm really sorry about sounding like a broken record here but the answer to your question is that it should pick the IPv6 address if you have IPv6 connectivity. This is standard behavior (RFC 3484) that can be overriden by local policy. All applications follow the same preferencing behavior to understand which protocol should be used when connecting to a host. The answer to your question is clear.
-4 and -6 flags are great if a host is reachable over both protocols and you want to test a specific protocol but the default behavior should be the same well defined standard that everything else on your system uses when it resolves a name to an ipaddress. getaddrinfo() is your friend.
Ping isn't intended to be a novice utility. It's a serious piece of a network diagnostic toolkit. Your grandma isn't going to be running it, so the harm of having it separated into two utilities is minor; anyone serious about network diagnostics and administration isn't going to be phased by the fact that there are two commands, one per protocol.
No it is not a minor issue. Many think that because their world is IPv4 only and they don't yet have to deal with a world running both protocols.
Like I said before and like I will undoubtably have to say a thousand times again before people start understanding there is no reliable way to know before you run the ping utility what protocol the destination host is running. Think about that for a second.
The other day I was trying to troubleshoot why I could not get to a carriers web site. I used ping but it returned the IPv4 address. The problem turned out to be an issue with IPv6 connectivity. I had no clue the site was on IPv6 and the v4 result I got back was less than useless.
There is one global namespace for DNS even though there are two IP protocols. There is no technical reason this is not a bug that will only annoy more and more people as the transition picks up steam. All the other major OS vendors seem to have it right...Whats wrong with Linux?
Sadly it seems IPv6 is just an extension to IPv4. Does it make any point eradicating existing IPv4 support as people still want those IPv4 addresses. Dual stack will probably stay for many years, if not 10 years.
"This domain has been reserved from registration."
RFC1112 muticast space needs L2/L3 multicast mapping traceroute utilities which has been around longer than I would like to admit... grrr.. i'm old...
I think we were talking about different things. I was talking about the difference between ping and traceroute that appear in Linux. Neither utility has any ability to ping an L2 address. Neither utility has any multicast support unless pinging the broadcast/multicast address counts as multicast support and all of the L2 details are abstracted by the kernel.
I'm sure your fancy "l3 switch" can trace through STP or whatever holds your L2 together but none of the above is relevent to ping and traceroute on linux.
Like I said before all traceroute amounts to is a bunch of ping incrementing the TTL each time. It is not rocket science.
the carriers will not route incoming connections to the devices, even with IPv6. This would endanger their current business models, so they will try to avoid it. It would be cool, when some important new App would really need incoming connections, so the carries virtually must support it. But i doubt they will, and there will be no such app. So the only thing they see is, that smartphones, tablets and other wanted consumer hardware should not have this feature, and tethering with notebooks is evil for them, anyway.
,,,aside from Comcast and Hurricane Electric?
I've killed a fair amount of IPv4 in our office already: http://www.terena.org/ipv6only
My only problem w/ the BSDs is that while configuring, they give you the options of only using EUI-64, and is not clear about how to disable it. Moreover, I'd like to know whether they include a DHCP6 client in the thing, so that one can set up the address configuration of the entire network based on whatver the best practices policies they have established, rather than just allow EUI-64 or a random ID.
Under Windows, it's just ping & traceroute - there are no separate commands like ping6. It's under the unixes that you have ping6.
huh?
block range of 32bit numbers VS block range of 128bit numbers?
I do not see what difference does it make to US government except maybe faster router CPU and more router RAM needed,
considering 11 trillion $ debt USA has i do not think buying more expensive model of CISCO gear will be deciding factor for them
The whole point in the transition is that you do not know ahead of time whether a host is IPv4 or IPv6. By not fixing ping and something does does not work you 'ping' it and the result you get is totally out of step with the way the rest of the operating system and your apps work.
Except that ping is not an app, it is a diagnostic tool. If you're in a dual-stack situation, you want to know whether a host is reachable over IPv4 or over IPv6 independently. You could do this with a -4 and -6 flag to ping, but then you'd need to type two more characters for the v6 version and three more for the v4 version.
I am TheRaven on Soylent News
And a coal plant can actually install cleaning filters that are a lot better than in cars. Usually doesn't get rid of the CO2, but a lot of the other nasty stuff at least.
Easier to install such stuff in a few places than in every car at least.
Erik Dalén
You have things totally backwards. The operating system figures out whether a host should be reached via ipv6 vs ipv4 based on your systems IPv6 connectivity and DNS. You can't know it in advance.
If I browse to www.slashdot.org and it has an AAAA record and my computer has IPv6 I get to slashdot via IPv6. Having ping being the only utility left on the fricking operating system that does not work this way is more broken than any nastalga.
You're probably going to have scripts out there that issue ping -n host.com and expect output like "64 bytes from bla.bla.bla.bla", and will fail if the output would suddenly change to "64 bytes from blabla:blabla:blabla::blabla".
Is it now? How hard is it to remove the IPv4 assignments from your network interfaces and lo? Oh, that was pretty easy. Took seconds.
Yes. But that isn't the point of it. Many people reuse code or put it to unintended usage. So just removing the IPv4 addresses from interfaces doesn't show if you can run a system without the IPv4 stack, because some code might be silently reused. That's a structural problem in the code. It might not even be visible at once or only to a small part of the comunity, but you really want to avoid that.
It is like having a kitchen table and the fourth leg is your kitchen aid. You no longer use the kitchen aid, because you got other tools in reach on the table, but removing the kitchen aid will topple all.
I'm sure there are a half billion scripts out there that expect to see "64 bytes from foo.com (xx.xx.xx.xx): ..." and will shit themselves when it becomes "64 bytes from foo.com [xxxx:xx::xxxx]: ..."
I thought about that too. But then I think that there are probably more scripts out there that only want to check for the reachability of foo.com by issuing "ping foo.com" or "ping -c 1 foo.com" and just checking the exit code or scanning for "64 bytes from foo.com". And all those scripts would then fail for an IPv6-only foo.com, but would succeed if the ping tool supported v4 and v6.
Sigh. So many things wrong there.
You can compile the kernel for IPv6 only. That is different then removing the code. What do you gain? Space. Fewer backdoors. Less bandwidth needed to push updates (but that ignores the overhead of 6 vs. 4).
Basically, there are many reasons to want to be 6 only, however, all are for specialized devices. Well, it happens that BSD is useful for just that.
Now, as to the electric car, in America, there are no places in the 48 that are 100% coal. The reason is that electricity moves all around. 3 different grids (west, texas, and east). Think water where multiple companies store water in a single place. As such, you get the %'s. Right now, that means that you get about 44% coal (dropping), 25% NG (rising), 20% nuke, with the rest being Alternative Energy (hydro, wind, solar, geo-thermal, etc and rising). Not only is that cleaner, but is nearly 100% not imported. It is also resistant to the massive price changes that oil is going through and about to get worse.
So, like the example that you used, electric cars are superior to gas/diesel in most situations (drive lots of long distances and fossil fuel wins) in just about every way.
I prefer the "u" in honour as it seems to be missing these days.
ping and traceroute have worked with 6 for sometime.
the others were developed when 6 and the kernel were undergoing loads of changes.
In the end, think grep, egrep, fgrep.
I prefer the "u" in honour as it seems to be missing these days.
You are running on 6 only. In Linux, if you do not have a 4 route, then ping will use the 6.
I prefer the "u" in honour as it seems to be missing these days.
And you do not have to. For example, if you ONLY have 6 (and no 4's), then ping will send 6. If you have both, THEN you must use a switch, or ping6. IOW, ping defaults to 4.
I prefer the "u" in honour as it seems to be missing these days.
I wish they would actually make transport-mode IPSEC compatible across different systems. Sure, it's a big pain to set up now anyway, but someone could write a GUI to generate a CA and certify different computers, etc. Windows already does this with its HomeGroup tech, and that's a quite elegant solution.
No need to set it to "0.0.0.0", you can just remove all IPv4 addresses from all interfaces and only add IPv6 addresses if you want.
For anyone that wants to easily enable his website to answer ipv6 request, use cloudflare, in addition to the many benefits of cloudflare, you can enable ipv6 by checking a checkbox : http://blog.cloudflare.com/introducing-cloudflares-automatic-ipv6-gatewa
I remember on ipv6 day that my Windows box preferred ipv6 over ipv4.
Libc gets involved since it translates the kernel calls into c functions.
It also adds some nice abstractions to the calls, but those are optional.
Rethinking email
That depends. If you run a public facing server, yes, you won't be able to get out of IPv4 soon. Now, if all you do is run clients and servers that only you care about, there is nothing stopping you from switching now... Except maybe for your ISP.
Rethinking email
FreeBSD does have a port with a dhcp6 client, but it's not built into the OS (base system) as far as I know. http://sourceforge.net/projects/wide-dhcpv6/ is in ports/net/dhcp6 i believe.
This actually brings up a good point and I should add a dhcp6 client to MidnightBSD. Not sure which one to use though.
MidnightBSD: The BSD for Everyone
No. In Linux, the ping command does not support IPv6, period. You need to use ping6.
Check for yourself:
# ping the IPv6 localhost ::1 ::1
baldur@pkunk:~$ ping -c1
ping: unknown host
baldur@pkunk:~$ ping6 -c1 ::1 ::1(::1) 56 data bytes ::1: icmp_seq=1 ttl=64 time=0.042 ms
PING
64 bytes from
--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.042/0.042/0.042/0.000 ms
# ping6 does not understand IPv4
baldur@pkunk:~$ ping -c1 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.083 ms
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.083/0.083/0.083/0.000 ms
baldur@pkunk:~$ ping6 -c1 127.0.0.1
unknown host
"It's easier to block a range of IP addresses than it is to manually insert random IPv6 addresses."
The first 64bits aren't random. They are much more linear than IPv4. It is easier to block a random block of IPv6 address than IPv4 addresses.
IPv6 takes *less* memory and CPU. While the entries take more space, you need fewer entries because it's more logically structured for routing.
Except that ping is not an app, it is a diagnostic tool. If you're in a dual-stack situation, you want to know whether a host is reachable over IPv4 or over IPv6 independently. You could do this with a -4 and -6 flag to ping, but then you'd need to type two more characters for the v6 version and three more for the v4 version.
No I don't. I don't give a flying rats ass who is dualstacked. All I want to know is why x is not working. By ping being the only app...err "diagnostic tool" which does not follow the same addressing standard everything else on my system uses to access network resources my job is harder not easier.
Actually windows 7 has at least folded ping and ping6 into one command, you add a flag to the ping command if you specifically want to use IPv6.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"I don't know about PXE but Linux NFS does work over IPv6. My home directory on the computer I'm using right now is an NFS share mounted over IPv6.
If IPv6 only breaks Skype, what is the problem? Nothing of value will be lost. There are plenty of SIP based clients our there that work perfectly well in IPv6 only. The reason for this is that they are open source.
Skype is closed source, and if they choose not to change and update their software, that's their choice. They will be left behind with all other internet dinosaurs. RealNetworks comes to mind.
Am I missing something? Why not just do something like (for RHEL), edit /etc/sysconfig/network to
NETWORKING_IPV4=0
NETWORKING_IPV6=1
Wouldn't that take care of it?
Ultimately, all that really 'takes care of' is the contents of some text file called /etc/sysconfig/network
not sure, but that may be out of date: http://www.perl.org/about/whitepapers/perl-ipv6.html
Of course, that doesn't help me, because my now former ISP was Qwest and they had a "we will never support IPv6" policy, so until CenturyLink (the purchaser) replaces all of the old hardware, I am SOL for my website and browsers (no, I'm not setting up a tunnel - I have better things to do with my time than figure that out). Setting my web server up will be easy when they add it - just update the DNS server entry (since even my DNS provider supports it). If I didn't hate Comcast or XFinity or whatever they want to be called with a passion I may have switched back, but DISH has been way too nice. On a scale of 1 to 10 my customer experience rating with Comcast: 1, with Qwest 3, with DISH 10. Note to CenturyLink - learn something from DISH, fix the broken that was Qwest, and avoid being Comcast except from a network performance level.
Just to restate: You don't care if a diagnostic tool is less deterministic and specific as long as you don't have to learn anything new to deal with new situations (like dualstack). Alright, thing I've got it now.
^I'm with stupid.^
Your comment makes no sense when thinking of a transition from IPv4 to IPv6. FreeBSD has made it so that it can run without IPv4 to make sure that there is nothing relying on IPv4. There will be a day when IPv4 is not needed, so why not make sure that nothing in IPv6 relies on it? FreeBSD has gotten over this hurdle and is now working on getting IPv6 performance up to the level of IPv4. They have assigned grant money to Bjoern Zeeb to get this project done, and the target is the end of Feb. They are lightyears ahead of other projects out there.
The advantage of the Microsoft approach is that you can also find out which path is preferred for a particular host.
Often, you not only need to know whether the site is available over a specific protocol, but also which (v4 or v6) is being used! For example, it may be possible that "ping xkcd.com" fails, but "ping6 xkcd.com" works fine (or vice versa). Depending on connectivity and the local prefix policy, the site may or may not work. As an alternative, maybe neither protocol works with ping. If your system prioritises v6, fixing your local v6 connectivity might restore access to the site.
I'm really sorry about sounding like a broken record here but the answer to your question is that it should pick the IPv6 address if you have IPv6 connectivity. This is standard behavior (RFC 3484) that can be overriden by local policy.
Sorry, but RFC 3484 isn't intended to apply to network architecture tools like ping, as it would introduce unpredictability. Indeed, RFC 3484 cautions against this in the Introduction:
In such cases, a simple policy to always prefer IPv6 or always prefer IPv4 can produce poor behavior.
Hence the "standard behaviour" your quote isn't what you think. Network architects and engineers need to be able to test connectivity for specific protocol families. Ping's job isn't some mushy "can I get some response for some domain name", it's "can I get a response from the host at address X".
No it is not a minor issue. Many think that because their world is IPv4 only and they don't yet have to deal with a world running both protocols.
I have not only run and maintained a dual-stack IPv4/IPv6 network for the last several years, I did some of my graduate research in this area, have taught advanced networking at the honours level at a major university, and have actually written an ICMPv6 library. I know what I'm talking about.
Like I said before and like I will undoubtably have to say a thousand times again before people start understanding there is no reliable way to know before you run the ping utility what protocol the destination host is running.
As I'll say now and hopefully won't have to say a thousand times more: you have no idea what you're talking about.
First off, of course ping has no way of knowing what protocol family the destination host is running. That's not its job, nor its purpose. Ping also can't automatically account for one host responding to multiple addresses (perfectly permissible in an IPv4-only network as well as an IPv4/IPv6 network). It can't account for hosts that don't respond to ICMP requests. It also can't account for servers that aren't listening on specific application ports, nor for server applications that don't return any data. If you are diagnosing network problems, those issues are YOUR job, not ping's. All that ping can do is test connectivity for a specific protocol family from one host to another, and report on the results. And you can only trust the results when they're positive and you're getting responses (if you don't get a response, that doesn't mean the host is down. It could simply be ignoring ICMP requests as many public hosts do these days).
The other day I was trying to troubleshoot why I could not get to a carriers web site. I used ping but it returned the IPv4 address. The problem turned out to be an issue with IPv6 connectivity. I had no clue the site was on IPv6 and the v4 result I got back was less than useless.
So you used the wrong tool for the job at hand, and your response is that the tool is at fault?
You could have run into exactly the same fault in an IPv4-only network. DNS doesn't enforce one name==one host; it is possible for one name to point to a number of hosts, with the local OS using some form of policy to choose between them (round robin, FIFO, random, etc.). Google is a good example -- ay my location, "dig google.com A +short" returns six different IPs. One or more of those could (theoretically) be offline at any given time, which won't be reflected by doing a simply "ping google.com" if ping picks the IP of a host that is online. If ping decides to use a different IP than my web browser, then I can't trust that the ping is representative of what I'd expect to see in the application.
This is an old problem, which predates IPv6. Proper network architects and developers know that the only way to properly debug such a situation is to know the address of the host your application is tr
Just to restate: You don't care if a diagnostic tool is less deterministic and specific as long as you don't have to learn anything new to deal with new situations (like dualstack). Alright, thing I've got it now.
If you didn't catch the hint from my previous message your 100% correct I simply don't want to know or care whether a site is IPv6, IPv4 or some combination of both... Why should I?
I want a diagnostic tool that follows RFC 3484 not some crappy artifact from ancient history when IPv6 support in the linux kernel was experimental and 3484 did not exist. I also want a tool that allows me to explicitly define the address family of my choice should I ever have a reason to care.
"you don't have to learn anything new to deal with new situations "
Ding Ding Ding... this is the whole fucking point of RFC 3484.