Is Slashdot intending to gather questions for 2 more years?
No, they are just pointing out that even two years from now, Bruce will still be one of the most influential. So why did they just say 15 and not some higher number? Maybe it will change before reaching 16, or maybe slashdot does not have access to information about the more distant future. We could check, if we knew their source of information about future events.
That's a business opportunity for you. You can buy them from the vendor and resell them in those countries where the vendor isn't selling them directly. I'm sure you can resell them with a huge margin. Just be careful with which countries you travel to afterwards. You may find yourself being wanted. After all, when it has been endorsed by the FSF, there is probably no code in there to prevent you from printing WMDs.
if you were interviewing a "network expert" who didn't know what "class A" meant, would you trust them?
As a matter of fact, I have interviewed plenty of people on networking. To this date, I don't know if any of them know what class A meant. I asked them questions, which I considered more important. If I had come across a candidate, who knew nothing about IPv4, but did have the level of expertise I was looking for in IPv6 instead, I would have recommend he be hired. But in reality I might never have found out, as I was mainly asking questions at a higher level.
You can explain how the hierarchy of networks and prefix lengths work without having to explain the entire history of classes and CIDR. With IPv6 I don't think you'll hear people talking about class A, B, and C networks, because the prefix lengths for those are only defined for IPv4. If you are teaching this stuff, you'll have to decide if you are teaching a history lesson or if you are teaching how it works. In the later case a lot of history should be left out.
it might well make sense for an introductory course to concentrate on a more simple model that beginners can more easily understand.
In that case teach IPv6 and skip the parts that nobody use. IPv6 is a little bit simpler than IPv4. There is not a huge difference, but there is certainly no point in teaching an obsolete technology for simplicity, when it isn't simpler. IPv4 is not entirely obsolete yet, but judging from the number of people who think IPv6 is more complicated than IPv4, I perceive that there must be a shortage of people who understand IPv6.
We're not obligated to prop up broken business models.
Adapt or die.
Their business model is not broken at all. The DNT header does not prevent them from keep doing what they have always been doing. The DNT header is entirely voluntary and cannot be enforced anyway, they can just ignore it. And with this move from Microsoft, they probably are going to ignore it. Then Microsoft will be sending a header, that is going to be ignored. Now, who is it that need to adapt again?
Because if every time the alarm goes off, it turns out to be a false positive, then it won't be treated with the respect it needs to. If one out of every 100 million people going through the gate is carrying a bomb, and if one out of every 100 thousand people going through the gate without explosives is triggering a false alarm, then once the alarm does go off, there is 99.9% probability that it is a false alarm.
I'm not saying the probability of a false alarm has to be less than the probability that a passenger picked at random actually is carrying a bomb. But they should at least be within an order of magnitude. If an alarm going off means 90% probability that it is a false alarm and 10% probability that the person is carrying a bomb, then the employees in the gate will probably take the alarm seriously.
The drawback of having a low false positive rate is that the employees might not know how to deal with false positives. It is hard to get experienced if you only experience once in your career that the alarm even goes off.
Actually I think there should have been three possible values for that header. User has opted in, user has opted out, and user has not taken initiative to change anything on his own. That would leave the default choice up to the websites, which I consider better than leaving the default choice up to the browser vendor. But more importantly, it would have made the semantics of the header slightly more clear than a boolean.
I wonder if this kind of thing pops up anywhere else?
Turns out there are actually three different possibilities. The browser can send "DNT: 1", "DNT: 0", or leave out the header. A server cannot distinguish between clients that leave out the header and those that simply don't support it. Then I noticed this unfortunate wording in the draft:
A user agent MAY adopt NO-EXPRESSED-PREFERENCE or OPT-OUT by default.
It MUST NOT transmit OPT-IN without explicit user consent.
If you permit opt-out as the default, then it isn't opt-out. So Microsoft is not violating the draft standard, they are using an option that the authors put in there. I don't think the authors have fully considered the implications of their wording. And Microsoft should still backtrack on their decision given the criticism they received. I do however hope the authors of the document realize they are at least partially responsible for this mess and they update the draft to clarify the intention.
And if a user picks IE10 because they know that it has DNT set by default, then ignoring the default setting is also undermining the purpose of the header.
I expect people who choose IE10 for that reason to be a minority of the IE10 users. Why would anybody choose IE10 for that reason? If you care about it, you can choose any of the browsers with support for the DNT header and set the preference the way you like.
With the number of differences between any two browser, why would the default value of a setting, which you can easily change, matter? Your choice of browser should be guided by those things you cannot change in the preferences.
If any significant percentage of IE10 users chose IE10 for any other reason, then the sites are correct in ignoring the default setting, since it tells them nothing. And users who actually want to tell sites, that they really don't want to be tracked, should choose a different browser, where their preference is less likely to be ignored.
When did the user give explicit permission to be tracked in the first place?
Who said they did?
Some sites provide content and services free of charge. In return they expect to make money from showing targeted ads to users. From those sites' point of view users who use the site are ok with that.
The sites may want to allow users to opt out from any tracking. And the header would allow users to opt out, since there was a value that would tell the site that this user has opted out and should instead be shown less targeted ads (as there is no longer any cookies to use for targeting). Any site who wanted to take that path is not going to do it now.
The header no longer tells the site anything. They can see some users sending do not track, which could mean they have opted out, but there is more than 90% probability, that it is send because that is what the browser does by default. They can see other users not sending it, which could mean they use a browser without support or just left the setting at its default value, either way there is more than 90% probability, that it is not send because that is what the browser does by default.
What this means is that regardless of what is send to the server, the most realistic interpretation of that value is that most likely the user didn't make any choice on their own. With that the header no longer serves any purpose.
The header could have allowed an opt-out model. But not anymore since both values can be send by default and will not tell you anything about user preference.
Exactly how would this be a detriment to the users?
It undermines the purpose of the header. Consider those places where websites are legally or morally obliged to respect any user who actively asks not to be tracked. A website in such a place would have been obliged to respect the header. But by enabling that header by default, Microsoft is undermining that obligation. When the header no longer means that the user has actively asked not to be tracked, then we cannot expect websites to treat it as such. And then we are back to a situation where users have no way of indicating, that they do not want to be tracked.
Actually I think there should have been three possible values for that header. User has opted in, user has opted out, and user has not taken initiative to change anything on his own. That would leave the default choice up to the websites, which I consider better than leaving the default choice up to the browser vendor. But more importantly, it would have made the semantics of the header slightly more clear than a boolean. And by making it possible for websites to really implement either opt-in or opt-out, then we can start pushing for sites to do one or the other. With only a boolean header and browsers behaving differently, you can't even draw a line between sites implementing opt-in and those implementing opt-out.
But ultimately, this header is just an attempt at patching over a model, which is fundamentally broken in the first place. Cookies were too easy to set when first introduced. Browsers were not working in the best interest of the user. Websites have been allowed to abuse cookies in ways that were not in the users' interest for far too long. By now any browser trying to serve the user better will end up providing users with a bad user experience because of many sites breaking. Had browsers been more restrictive in the first place, then sites wouldn't have been using cookies in the ways they do now.
Let's face it. Nothing is going to change unless Google, Microsoft and Mozilla can agree to move together. Because they each have such large fractions of the browser market. If they can agree on a new model, which works in the user's interest and is enforceable by the browser, then things will change.
To the best of my knowledge, there has never been a time that an arbitrary Internet user, sending or receiving IP packets to another arbitrary Internet user not on the same ISP, has been able to avoid unknown third party relays.
Wrong. There is a customer relationship between the parties who are communicating and the networks, which are forwarding the packets. Those companies aren't forwarding exabits of traffic without receiving payment for it.
You pay your internet provider for internet access. They probably don't cover the entire world with their network, so they have multiple subcontractors, who operate worldwide backbones but no access networks. The subcontractors can also have subcontractors. I think three levels is a typical depth of this hierarchy, but it could be deeper.
That way you are paying for connectivity between your computer and lots of central communication points. You don't pay for connectivity to every little corner of the world though. The parties you communicate with pay for connectivity between their computer and lots of central communication points. As long as the networks you pay for access to overlap at some place, you can communicate. That's why it works great.
Run a traceroute between your computer and any IP on the internet. Each of the hops you see on the path is paid for by one of the endpoints. In some cases there may be a bit of overlap in the middle, where one provider is receiving payment from both sides. Too much of that kind of double payment puts incentive on companies further down the chain to set up their own peerings.
Try the same with third party relays as used by 6to4 or Teredo. First of all, you don't actually have full visibility into the path the traffic takes. Secondly there can be a part in the middle, which is not actually paid for by either end, and as such has little obligation to forward the packets. But the worst part is, that when it fails, it is very hard to find out who is responsible.
"You no longer have to worry about unicast, multicast, and broadcast, it's now just unicast and multicast."
If you are a system administrator, just pretend it's the same thing. It will probably be several years before you need to know the differences. If you are actually implementing code to handle IPv6 packets on Ethernet, then you need to lookup the details now.
Sounds like change for change's sake to call "broadcast" "all-points multicast" when they are functionally identical.
They are functionally identical if you are running it on switches that don't know the difference. In 20 years when you have gotten rid of all the broadcast traffic caused by IPv4 and your switches know to only send multicast packets to nodes that need them, then you can grow the network segments to a much larger number of nodes.
This is one of those changes, which may help us at some point in the future. For now you can ignore it as it introduces no operational difference compared to what you have been used to.
I can think of one place where there has been a naming change, but where IPv4 and IPv6 are actually identical. It is the TTL field from IPv4, which is called hop limit in IPv6. The point is that the TTL field as it was originally specified was basically impossible to implement. Thus actual IPv4 implementations deviated a little bit from the spec. With IPv6 the spec was changed to match what everybody have been doing, and the field was renamed accordingly.
For you, a DNS server is nothing. You've probably got 20 of them running in your labs.
Only 19. But then again, this is a one man company, and I don't have a big lab. What I really like about working with IPv6 is that whenever I need to add a component to my system, I just assign another IPv6 address to it without even having to think twice, because I know there will be enough IPv6 addresses. 11 of the DNS servers I have running at this time are authoritative DNS servers, which I actually run IPv6 only. On each domain I host on those, I have some special feature I need on that domain. I don't need to worry about interaction between those features, because I run each server as a separate process. That is something I couldn't have done, if I had been using IPv4, because there are just not enough addresses.
I am connecting from Europe. Some routing issues, perhaps?
A routing issue is a possibility. But I am connecting from Europe as well, and it works for me.
Through HE tunnel server in Frankfurt:
traceroute to 2600:1406:12:1:8700::fc4 (2600:1406:12:1:8700::fc4), 30 hops max, 80 byte packets 1 2a01:d0:839a:babe:d19e:266e:d66c:545c 4.919 ms 0.154 ms 0.172 ms 2 2001:470:1f0a:1e45::1 45.807 ms 49.123 ms 54.393 ms 3 2001:470:0:69::1 60.570 ms 39.561 ms 41.584 ms 4 2001:470:0:21b::2 48.480 ms 48.813 ms 48.700 ms 5 2001:470:0:21e::1 56.056 ms 65.149 ms 65.723 ms 6 2001:470:0:128::1 124.572 ms 124.899 ms 123.429 ms 7 2001:470:0:1c6::2 136.970 ms 141.566 ms 142.074 ms 8 2001:470:0:120::2 141.782 ms 141.817 ms 136.904 ms 9 2400:8800:7f02:1::2 184.937 ms 193.048 ms 194.179 ms 10 2400:8800:7f02:1::2 198.687 ms 199.216 ms 198.695 ms 11 2600:1406:12:1:8700::fc4 198.648 ms 187.428 ms 187.897 ms
When I tried again with a hostname, my tunnelling software had found a shorter route:
traceroute to whitehouse.gov (2a02:26f0:32:2:8f00::fc4), 30 hops max, 80 byte packets 1 2a01:d0:839a:babe:d19e:266e:d66c:545c 0.122 ms 0.114 ms 0.142 ms 2 2001:668:106:ffff:: 40.309 ms 40.358 ms 41.050 ms 3 2a02:26f0:32:2:8f00::fc4 39.743 ms 38.050 ms 38.344 ms
Through HE tunnel server in Stockholm
traceroute to whitehouse.gov (2a02:26f0:18:1:8d00::fc4), 30 hops max, 80 byte packets 1 2001:470:28:940:5d75:c1f4:e0a0:f8ec 0.415 ms 0.797 ms 13.577 ms 2 2001:470:27:940::1 45.053 ms 49.645 ms 43.469 ms 3 2001:470:0:11e::1 47.340 ms 21.571 ms 25.712 ms 4 2001:7f8:d:fc::170 29.475 ms 33.473 ms 34.786 ms 5 2a02:26f0:18:1:8d00::fc4 39.011 ms 35.595 ms 39.187 ms
traceroute to 2600:1406:12:1:8700::fc4 (2600:1406:12:1:8700::fc4), 30 hops max, 80 byte packets 1 2001:470:28:940:5d75:c1f4:e0a0:f8ec 0.850 ms 0.919 ms 5.134 ms 2 2001:470:27:940::1 45.167 ms 49.519 ms 49.772 ms 3 2001:470:0:11e::1 50.197 ms 29.384 ms 36.539 ms 4 2001:470:0:22f::1 74.427 ms 75.348 ms 71.452 ms 5 2001:470:0:3f::1 81.067 ms 81.173 ms 81.611 ms 6 2001:470:0:128::1 149.678 ms 150.250 ms 143.576 ms 7 2001:470:0:1c6::2 159.699 ms 139.553 ms 143.250 ms 8 2001:470:0:120::2 148.932 ms 154.046 ms 163.290 ms 9 2400:8800:7f02:1::2 212.706 ms 237.569 ms 238.143 ms 10 2400:8800:7f02:1::2 238.091 ms 239.887 ms 240.193 ms 11 2600:1406:12:1:8700::fc4 240.519 ms 253.809 ms 257.508 ms
Notice that the less than 40ms I got on one of the IPs is too low for a trip across the Atlantic, so it must be hosted in Europe or nearby. A whois on the IP addresses reveals that this is Akamai. Knowing which provider you are using and seeing a traceroute from your network may help identify where the problem is. But it sounds like it is somewhere between your provider and Akamai.
And I wasn't saying that I wouldn't want IPv6 without NAT, just that the IPv6 fundamentalists won't allow people to say that NAT has been useful in some circumstances.
It has been useful. But I think with IPv6 I think there are better solutions in every situation, where you would use NAT66. If a customer came to me asking for NAT66, I would try to reason with them. I don't want customers to deploy an inferior solution due to being uninformed. But if a customer who understands what the options are still want NAT66, I'd be happy to implement it, if they would pay.
When I go to an internet provider, I would like them to treat me the same way. And that means I don't want them to tell me I don't need IPv6. They can tell me they don't think it is ready, and why, but if I with all the information at hand still want it, it's not their job to tell me out of it. I also don't like how some internet providers think they should take extra high payments from those customers, who are willing to be guinea pigs.
As for the rest of the internet, who I do not have any customer relationship with, I don't care how they handle their own LAN and the connectivity between their LAN and the backbone. But I do care about the protocol being used on the backbone, because those only doing IPv4 there are holding back the development of the internet for the rest of us. For all of those people I'd rather see them use NAT66 than NAT44.
There is nothing in the IPv6 protocol preventing NAT66, there are less obstacles in the protocol than with IPv4. And you are free to use it, if you want to. But you will have a hard time convincing me that you know what you are doing, if you decide to deploy NAT66. But then again, the majority of companies on the internet will have a hard time convincing me that they know what they are doing anyway.
why do you have to do ping6? Why not just have ping check the format of the passed argument and call classic ping or ping6 appropriately?
That does not have anything to do with the IPv6 protocol. That is entirely an implementation question, and I believe some systems have a ping command, which does IPv4 and IPv6. I don't think the minor differences in command lines between different operating systems have any influence on the speed at which IPv6 is being deployed.
That would be like Windows users saying, "How can you do X on Linux", and the response being "Don't do X."
It works the other way too. Back when I was in a job, where I was forced to use Windows, I would often ask questions about, how do I do X in Windows. I wasn't told don't do X, I was just told, you cannot do X in Windows.
Also, doing SSH to IPv6 hosts named in/etc/hosts has been problematic for me to the extent that I've just forgone my initial attempts at local IPv6.
I haven't actually tried that. Rather I went the way of putting my hosts in DNS. In those cases where I need to access a host, which I did not put in DNS yet, I have a zone, which automatically generates AAAA records. That way I can do such stuff as 2a00-1450-400f-800--100e.aaaa.kasperd.net, and it works.
scp even works differently than ssh in this regard. In one or the other of the two, you can't do luser@[IPv6], although luser@1.2.3.4 works just fine.
Yeah, that is a bit annoying. But most of the time i do ssh to hostnames anyway. I rarely do ssh to an IP address.
Which will make the server inaccessible to anybody using Teredo. And that is not the only system doing something like that. I have a system which will ping the site through two different tunnels to use the most reliable path to the server.
It would be incredibly stupid if they added the AAAA-record and you couldn't connect to it.
I know of an ISP who did that for their homepage. When I questioned them about it, they said it was a deliberate choice.
But in this case of whitehouse.gov I do get responses for both ICMP echo requests and HTTP requests to the IPv6 addresses in their AAAA records. So either the GP is mistaken, or they changed the configuration on the server.
Come on, just let people have their NATs, why don't you?
NAT wasn't part of the IPv4 standard. It got implemented anyway. Some standards got written at some point. But vendors can still produce IPv4 NAT solutions however they please and ignore the standards. Nothing stops vendors from producing IPv6 NAT solutions. There aren't any written standards. But in reality IPv6 is better suited for NAT solutions than IPv4 was.
IPID field was eliminated from the IP header. I am not aware of any IPv4 NAT even trying to handle that field correctly. It's a good thing it isn't in the IPv6 header.
In those rare cases where you need an IPID field it is in an extension header and twice the size of what it was in IPv4. That reduces the risk of collisions.
RFC1918 addresses have no method for avoiding collisions. RFC 4193 is designed to reduce risk of collisions.
With IPv4 you'd often need to NAT behind a single IPv4 address, and often one which was simultaneously assigned to the node doing NAT. This dual use of the single address introduces conflicts. With IPv6 you could NAT with a/64 range, and you can avoid using the address assigned to that node for NAT. That avoids conflicts due to two usages of the same address. And with enough IPv6 addresses available, you can use port preserving on the NAT.
When an IPv6 NAT can be so much better why aren't they widely used? My guess is nobody wants them. I think the people who ask for NAT with IPv6 just wants an excuse to not have to work on upgrading their network. If NAT was available for IPv6, they'd have found another excuse. Those who really do want IPv6 and will take the effort to upgrade will want to avoid the additional complexity of NAT. And nobody really have a usecase where NAT between IPv6 and IPv6 is making anything easier.
NAT where you have IPv4 on one side and IPv6 on the other side can make sense in some scenarios. If your LAN is IPv6 only and you want to communicate with servers on an IPv4 backbone, you can use DNS64+NAT64. If your LAN is IPv4 only and you want to communicate with an IPv6 backbone, there are fewer options. (I decided to actually go and implement one.)
but you can also just implement the firewall without NAT and get the same level of security.
I think the firewall without NAT is more secure. Getting rid of NAT means you reduce complexity a lot. Less complexity means less risk of security bugs in the implementation.
I actually prefer 6to4. It's less efficient, but reverse DNS is guaranteed to work
What good is reverse DNS if you cannot communicate. 6to4 works great when communicating with another 6to4 address. But as soon as you communicate with a native IPv6 address you are relying on two third party relays to handle traffic in both directions. You won't even know whose third party relay you were using at the point where it stops working.
If this happens we may not see IPv6 for another 15 years at LEAST.
All 221/8 networks had been handed out by February of last year. If you extrapolate the growth curve, you'll find the usage would have reached 442 in less than 10 years from now. What it is going to happen to the users who would have been in those other 221 blocks? I think a significant portion will get some sort of IPv6 access. Additionally take into account that the first/8 networks which were handed out are less efficiently utilized than the last. The growth of another 221/8 blocks you get from extrapolation would have been with very dense utilization.
If you take all of that into account, it is very likely that 10 years from now, there will be more people on IPv6 only than on IPv4 only. And since it is much easier to get dual stack to all of those who are currently IPv4 only than to get public IPv4 addresses enough for another few billion users, deployments of dual stack will accelerate a long time before IPv6 reaches the same level of deployment as IPv4.
I don't see how IPv4 can still be relevant 15 years from now.
Slashdot Mirror
No, they are just pointing out that even two years from now, Bruce will still be one of the most influential. So why did they just say 15 and not some higher number? Maybe it will change before reaching 16, or maybe slashdot does not have access to information about the more distant future. We could check, if we knew their source of information about future events.
He proposes deploying antennas using inflatable balloons
Did he forget that the Moon does not have any atmosphere?
That's a business opportunity for you. You can buy them from the vendor and resell them in those countries where the vendor isn't selling them directly. I'm sure you can resell them with a huge margin. Just be careful with which countries you travel to afterwards. You may find yourself being wanted. After all, when it has been endorsed by the FSF, there is probably no code in there to prevent you from printing WMDs.
if you were interviewing a "network expert" who didn't know what "class A" meant, would you trust them?
As a matter of fact, I have interviewed plenty of people on networking. To this date, I don't know if any of them know what class A meant. I asked them questions, which I considered more important. If I had come across a candidate, who knew nothing about IPv4, but did have the level of expertise I was looking for in IPv6 instead, I would have recommend he be hired. But in reality I might never have found out, as I was mainly asking questions at a higher level.
You can explain how the hierarchy of networks and prefix lengths work without having to explain the entire history of classes and CIDR. With IPv6 I don't think you'll hear people talking about class A, B, and C networks, because the prefix lengths for those are only defined for IPv4. If you are teaching this stuff, you'll have to decide if you are teaching a history lesson or if you are teaching how it works. In the later case a lot of history should be left out.
there is a lot to talk about in terms of the physical and data link layers and plain IPv4 before even addressing IPv6.
It would be better to teach plain IPv6 before you start addressing IPv4.
In that case teach IPv6 and skip the parts that nobody use. IPv6 is a little bit simpler than IPv4. There is not a huge difference, but there is certainly no point in teaching an obsolete technology for simplicity, when it isn't simpler. IPv4 is not entirely obsolete yet, but judging from the number of people who think IPv6 is more complicated than IPv4, I perceive that there must be a shortage of people who understand IPv6.
We're not obligated to prop up broken business models.
Adapt or die.
Their business model is not broken at all. The DNT header does not prevent them from keep doing what they have always been doing. The DNT header is entirely voluntary and cannot be enforced anyway, they can just ignore it. And with this move from Microsoft, they probably are going to ignore it. Then Microsoft will be sending a header, that is going to be ignored. Now, who is it that need to adapt again?
Because if every time the alarm goes off, it turns out to be a false positive, then it won't be treated with the respect it needs to. If one out of every 100 million people going through the gate is carrying a bomb, and if one out of every 100 thousand people going through the gate without explosives is triggering a false alarm, then once the alarm does go off, there is 99.9% probability that it is a false alarm.
I'm not saying the probability of a false alarm has to be less than the probability that a passenger picked at random actually is carrying a bomb. But they should at least be within an order of magnitude. If an alarm going off means 90% probability that it is a false alarm and 10% probability that the person is carrying a bomb, then the employees in the gate will probably take the alarm seriously.
The drawback of having a low false positive rate is that the employees might not know how to deal with false positives. It is hard to get experienced if you only experience once in your career that the alarm even goes off.
Actually I think there should have been three possible values for that header. User has opted in, user has opted out, and user has not taken initiative to change anything on his own. That would leave the default choice up to the websites, which I consider better than leaving the default choice up to the browser vendor. But more importantly, it would have made the semantics of the header slightly more clear than a boolean.
I wonder if this kind of thing pops up anywhere else?
I took a closer look at the standards draft: http://tools.ietf.org/html/draft-mayer-do-not-track-00
Turns out there are actually three different possibilities. The browser can send "DNT: 1", "DNT: 0", or leave out the header. A server cannot distinguish between clients that leave out the header and those that simply don't support it. Then I noticed this unfortunate wording in the draft:
A user agent MAY adopt NO-EXPRESSED-PREFERENCE or OPT-OUT by default. It MUST NOT transmit OPT-IN without explicit user consent.
If you permit opt-out as the default, then it isn't opt-out. So Microsoft is not violating the draft standard, they are using an option that the authors put in there. I don't think the authors have fully considered the implications of their wording. And Microsoft should still backtrack on their decision given the criticism they received. I do however hope the authors of the document realize they are at least partially responsible for this mess and they update the draft to clarify the intention.
I expect people who choose IE10 for that reason to be a minority of the IE10 users. Why would anybody choose IE10 for that reason? If you care about it, you can choose any of the browsers with support for the DNT header and set the preference the way you like.
With the number of differences between any two browser, why would the default value of a setting, which you can easily change, matter? Your choice of browser should be guided by those things you cannot change in the preferences.
If any significant percentage of IE10 users chose IE10 for any other reason, then the sites are correct in ignoring the default setting, since it tells them nothing. And users who actually want to tell sites, that they really don't want to be tracked, should choose a different browser, where their preference is less likely to be ignored.
Who said they did?
Some sites provide content and services free of charge. In return they expect to make money from showing targeted ads to users. From those sites' point of view users who use the site are ok with that.
The sites may want to allow users to opt out from any tracking. And the header would allow users to opt out, since there was a value that would tell the site that this user has opted out and should instead be shown less targeted ads (as there is no longer any cookies to use for targeting). Any site who wanted to take that path is not going to do it now.
The header no longer tells the site anything. They can see some users sending do not track, which could mean they have opted out, but there is more than 90% probability, that it is send because that is what the browser does by default. They can see other users not sending it, which could mean they use a browser without support or just left the setting at its default value, either way there is more than 90% probability, that it is not send because that is what the browser does by default.
What this means is that regardless of what is send to the server, the most realistic interpretation of that value is that most likely the user didn't make any choice on their own. With that the header no longer serves any purpose.
The header could have allowed an opt-out model. But not anymore since both values can be send by default and will not tell you anything about user preference.
Exactly how would this be a detriment to the users?
It undermines the purpose of the header. Consider those places where websites are legally or morally obliged to respect any user who actively asks not to be tracked. A website in such a place would have been obliged to respect the header. But by enabling that header by default, Microsoft is undermining that obligation. When the header no longer means that the user has actively asked not to be tracked, then we cannot expect websites to treat it as such. And then we are back to a situation where users have no way of indicating, that they do not want to be tracked.
Actually I think there should have been three possible values for that header. User has opted in, user has opted out, and user has not taken initiative to change anything on his own. That would leave the default choice up to the websites, which I consider better than leaving the default choice up to the browser vendor. But more importantly, it would have made the semantics of the header slightly more clear than a boolean. And by making it possible for websites to really implement either opt-in or opt-out, then we can start pushing for sites to do one or the other. With only a boolean header and browsers behaving differently, you can't even draw a line between sites implementing opt-in and those implementing opt-out.
But ultimately, this header is just an attempt at patching over a model, which is fundamentally broken in the first place. Cookies were too easy to set when first introduced. Browsers were not working in the best interest of the user. Websites have been allowed to abuse cookies in ways that were not in the users' interest for far too long. By now any browser trying to serve the user better will end up providing users with a bad user experience because of many sites breaking. Had browsers been more restrictive in the first place, then sites wouldn't have been using cookies in the ways they do now.
Let's face it. Nothing is going to change unless Google, Microsoft and Mozilla can agree to move together. Because they each have such large fractions of the browser market. If they can agree on a new model, which works in the user's interest and is enforceable by the browser, then things will change.
Wrong. There is a customer relationship between the parties who are communicating and the networks, which are forwarding the packets. Those companies aren't forwarding exabits of traffic without receiving payment for it.
You pay your internet provider for internet access. They probably don't cover the entire world with their network, so they have multiple subcontractors, who operate worldwide backbones but no access networks. The subcontractors can also have subcontractors. I think three levels is a typical depth of this hierarchy, but it could be deeper.
That way you are paying for connectivity between your computer and lots of central communication points. You don't pay for connectivity to every little corner of the world though. The parties you communicate with pay for connectivity between their computer and lots of central communication points. As long as the networks you pay for access to overlap at some place, you can communicate. That's why it works great.
Run a traceroute between your computer and any IP on the internet. Each of the hops you see on the path is paid for by one of the endpoints. In some cases there may be a bit of overlap in the middle, where one provider is receiving payment from both sides. Too much of that kind of double payment puts incentive on companies further down the chain to set up their own peerings.
Try the same with third party relays as used by 6to4 or Teredo. First of all, you don't actually have full visibility into the path the traffic takes. Secondly there can be a part in the middle, which is not actually paid for by either end, and as such has little obligation to forward the packets. But the worst part is, that when it fails, it is very hard to find out who is responsible.
If you are a system administrator, just pretend it's the same thing. It will probably be several years before you need to know the differences. If you are actually implementing code to handle IPv6 packets on Ethernet, then you need to lookup the details now.
They are functionally identical if you are running it on switches that don't know the difference. In 20 years when you have gotten rid of all the broadcast traffic caused by IPv4 and your switches know to only send multicast packets to nodes that need them, then you can grow the network segments to a much larger number of nodes.
This is one of those changes, which may help us at some point in the future. For now you can ignore it as it introduces no operational difference compared to what you have been used to.
I can think of one place where there has been a naming change, but where IPv4 and IPv6 are actually identical. It is the TTL field from IPv4, which is called hop limit in IPv6. The point is that the TTL field as it was originally specified was basically impossible to implement. Thus actual IPv4 implementations deviated a little bit from the spec. With IPv6 the spec was changed to match what everybody have been doing, and the field was renamed accordingly.
Only 19. But then again, this is a one man company, and I don't have a big lab. What I really like about working with IPv6 is that whenever I need to add a component to my system, I just assign another IPv6 address to it without even having to think twice, because I know there will be enough IPv6 addresses. 11 of the DNS servers I have running at this time are authoritative DNS servers, which I actually run IPv6 only. On each domain I host on those, I have some special feature I need on that domain. I don't need to worry about interaction between those features, because I run each server as a separate process. That is something I couldn't have done, if I had been using IPv4, because there are just not enough addresses.
A routing issue is a possibility. But I am connecting from Europe as well, and it works for me.
Through HE tunnel server in Frankfurt:
When I tried again with a hostname, my tunnelling software had found a shorter route:
Through HE tunnel server in Stockholm
Notice that the less than 40ms I got on one of the IPs is too low for a trip across the Atlantic, so it must be hosted in Europe or nearby. A whois on the IP addresses reveals that this is Akamai. Knowing which provider you are using and seeing a traceroute from your network may help identify where the problem is. But it sounds like it is somewhere between your provider and Akamai.
It has been useful. But I think with IPv6 I think there are better solutions in every situation, where you would use NAT66. If a customer came to me asking for NAT66, I would try to reason with them. I don't want customers to deploy an inferior solution due to being uninformed. But if a customer who understands what the options are still want NAT66, I'd be happy to implement it, if they would pay.
When I go to an internet provider, I would like them to treat me the same way. And that means I don't want them to tell me I don't need IPv6. They can tell me they don't think it is ready, and why, but if I with all the information at hand still want it, it's not their job to tell me out of it. I also don't like how some internet providers think they should take extra high payments from those customers, who are willing to be guinea pigs.
As for the rest of the internet, who I do not have any customer relationship with, I don't care how they handle their own LAN and the connectivity between their LAN and the backbone. But I do care about the protocol being used on the backbone, because those only doing IPv4 there are holding back the development of the internet for the rest of us. For all of those people I'd rather see them use NAT66 than NAT44.
There is nothing in the IPv6 protocol preventing NAT66, there are less obstacles in the protocol than with IPv4. And you are free to use it, if you want to. But you will have a hard time convincing me that you know what you are doing, if you decide to deploy NAT66. But then again, the majority of companies on the internet will have a hard time convincing me that they know what they are doing anyway.
That does not have anything to do with the IPv6 protocol. That is entirely an implementation question, and I believe some systems have a ping command, which does IPv4 and IPv6. I don't think the minor differences in command lines between different operating systems have any influence on the speed at which IPv6 is being deployed.
It works the other way too. Back when I was in a job, where I was forced to use Windows, I would often ask questions about, how do I do X in Windows. I wasn't told don't do X, I was just told, you cannot do X in Windows.
I haven't actually tried that. Rather I went the way of putting my hosts in DNS. In those cases where I need to access a host, which I did not put in DNS yet, I have a zone, which automatically generates AAAA records. That way I can do such stuff as 2a00-1450-400f-800--100e.aaaa.kasperd.net, and it works.
Yeah, that is a bit annoying. But most of the time i do ssh to hostnames anyway. I rarely do ssh to an IP address.
Which will make the server inaccessible to anybody using Teredo. And that is not the only system doing something like that. I have a system which will ping the site through two different tunnels to use the most reliable path to the server.
I know of an ISP who did that for their homepage. When I questioned them about it, they said it was a deliberate choice.
But in this case of whitehouse.gov I do get responses for both ICMP echo requests and HTTP requests to the IPv6 addresses in their AAAA records. So either the GP is mistaken, or they changed the configuration on the server.
NAT wasn't part of the IPv4 standard. It got implemented anyway. Some standards got written at some point. But vendors can still produce IPv4 NAT solutions however they please and ignore the standards. Nothing stops vendors from producing IPv6 NAT solutions. There aren't any written standards. But in reality IPv6 is better suited for NAT solutions than IPv4 was.
When an IPv6 NAT can be so much better why aren't they widely used? My guess is nobody wants them. I think the people who ask for NAT with IPv6 just wants an excuse to not have to work on upgrading their network. If NAT was available for IPv6, they'd have found another excuse. Those who really do want IPv6 and will take the effort to upgrade will want to avoid the additional complexity of NAT. And nobody really have a usecase where NAT between IPv6 and IPv6 is making anything easier.
NAT where you have IPv4 on one side and IPv6 on the other side can make sense in some scenarios. If your LAN is IPv6 only and you want to communicate with servers on an IPv4 backbone, you can use DNS64+NAT64. If your LAN is IPv4 only and you want to communicate with an IPv6 backbone, there are fewer options. (I decided to actually go and implement one.)
I think the firewall without NAT is more secure. Getting rid of NAT means you reduce complexity a lot. Less complexity means less risk of security bugs in the implementation.
2016 is way too late. Should have said 2008.
What good is reverse DNS if you cannot communicate. 6to4 works great when communicating with another 6to4 address. But as soon as you communicate with a native IPv6 address you are relying on two third party relays to handle traffic in both directions. You won't even know whose third party relay you were using at the point where it stops working.
All 221 /8 networks had been handed out by February of last year. If you extrapolate the growth curve, you'll find the usage would have reached 442 in less than 10 years from now. What it is going to happen to the users who would have been in those other 221 blocks? I think a significant portion will get some sort of IPv6 access. Additionally take into account that the first /8 networks which were handed out are less efficiently utilized than the last. The growth of another 221 /8 blocks you get from extrapolation would have been with very dense utilization.
If you take all of that into account, it is very likely that 10 years from now, there will be more people on IPv6 only than on IPv4 only. And since it is much easier to get dual stack to all of those who are currently IPv4 only than to get public IPv4 addresses enough for another few billion users, deployments of dual stack will accelerate a long time before IPv6 reaches the same level of deployment as IPv4.
I don't see how IPv4 can still be relevant 15 years from now.
Both.