why is everyone here against EE? Is it because they attempt to charge you for the answer?
I'll tell you what I don't like about it. I don't mind them charging for an answer when both the person who asked the question, and the person who gave the answer is ok with that. On the other hand, I am not an ExpertsExchange user, and I do not think that it is ok that they charge for access to answers that I wrote.
I know there are ways to get to see the answer without paying, and that is why I know that some of the answers are nothing but a link to a webpage where I provided the answer to the question (before it was even asked on ExpertSexchange). So far I haven't decided what to do about this. I could direct the users who access my site by using a link from ExpertsExchange through an interstitial page, but that would seem like punishing the users instead. But maybe if I used the page not just to point out my opinion about that site, but to also mention free alternatives, then it may be ok. I have also considered telling ExpertsExchange to make all pages with links to my pages freely available. (If newspapers can claim it is a copyright violation to link to their news, then I should be able to make similar requirements to ExpertsExchange. But it does feel going a bit against my principles because I think linking directly to pages with relevant information is what the web is all about).
But what I dislike even more than sites charging for access to answers, that are little more than a link to my site, is those fake forums that pretend I am a user of their site. But in reality the entire content of that forum site is a ripoff of a selection of usenet groups. I'd feel much better about claiming copyright violation against such sites because they actually have copied content copyrighted by me. On the other hand, it seems a bit futile to try to go against all of those sites that way. And it may be difficult to draw a line between a legitimate webinterface for usenet, and a blatant ripoff. However, one distinguishing feature is whether the site makes it clear that it is a webinterface for usenet, or whether it pretends to be a amazingly popular webforum. Another distinguishing feature is whether it focuses on a (small) group of users that use it as their way to access usenet, or if the site simply try to attract all kinds of users from every searchengine out there, and just throw tons of ads at the users (with a little bit of copied content in between).
I don't know what blocksize ECC memory uses. It would make sense to use one line of the DRAM memory, because if you don't actually correct errors during refresh, then the probability of an uncorrectable error increases the longer a memory location has remained untouched. Without correction, you could be reading out bad data and writing it back. And the memory would be accumulating errors.
I have seen computers where one work and the other doesn't. But I'll have to admit, that most of my issues with it could be resolved by fixing the software, and no new hardware would be required.
With the laptops I currently have, the situation is as follows. My work laptop (MacBook Pro) is configured to automatically suspend to RAM and disk simultaneously. And this works flawlessly until it actually need to resume from disk at which point it crashes and reboots. My older personal laptop by default suspend to RAM and crash when resumed, but if I remember to suspend to disk it does actually resume just fine 95% of the time. My newer personal laptop by default suspend to RAM as soon as I close the screen, and it resumes just fine. I didn't try to figure out how to make it suspend to disk.
There is a couple of general issues with the suspend functionality. If storage encryption is in use, most implementations suffer from the serious flaw of keeping the key around while suspended. They make this mistake both when suspending to RAM and when suspending to disk. However I believe extracting the key from RAM requires a bit more skill than extracting it from disk.
Finally the estimate of how much battery is left is not always accurate enough to have the system automatically suspend before power runs out. And this may be the only issue on my list that would require hardware changes to fix. All the other ones are simply software bugs that need to be fixed.
There are ways to work around this by introducing on-the-fly error correction. But this will result in a larger device and added latency, which is obviously not desired in many applications.
Aren't you going to need this on-the-fly error correction in every system where you don't want a random bitflip to happen every once in a while? I would assume the data going between the DRAM and the SRAM in the control part of the chip would always go through some ECC logic both ways, except on those chips where it was cut out in order to reduce cost.
Indeed. The number of possible write cycles is important if you wanted to replace RAM. I'd wish we had a kind of memory with all the properties that would be important to use it as swap space. That means many write cycles, performance better than flash and hard disk (but not necessarily as fast as DRAM), and finally price and density that is closer to flash than to DRAM.
Fast and durable does have its places. Imagine if you could design a computer where you didn't have to worry about losing power for a short period of time because once the power returned, the entire contents of RAM would still be there and you could just resume where it left off. It would eliminate the need for a UPS in some places (but not in all places). And it would mean you didn't have to ensure that your laptop was suspended before battery runs out, and you don't lose what you were working on in case the battery does run out while suspended.
but rebooting would have to include zeroing all of the memory.
Not necessary. The operating system already has to assume there could be random garbage in all the memory it didn't touch. The operating system has to zero the memory before handing it to applications. And that is the case even if it was zeroed on boot. It could be a long time since the system was booted, and the memory may have been used for something in the meantime. Some operating systems keep a cache of zeroed pages that can be handed to applications as needed, others do it on demand.
I wonder if it's practical to zero the memory after a PC is shutdown. Kind of a background routine.
If you want the hardware to be modified slightly to achieve it, then it should be completely practical. DRAM doesn't write individual cells at a time. It reads out entire lines of bits into SRAM modifies it there and writes it back. Moreover it even periodically sweeps over the lines just reading them out and writing them back to refresh them.
I don't know how long time the sweep takes, but for wiping the memory you could speed it up. The control logic have a number of outgoing lines with a binary number indicating which line of cells to read or write. Each line has a decoding unit to know when its number is up. If you added a line to select all lines simultaneously and OR that line with the output of the existing decoding unit, it sounds feasible that the control logic could in fact write the contents of the SRAM to all lines in parallel.
If this works you could wipe memory in less than a microsecond.
I have heard much more stupid suggestions on how to improve privacy. One suggestion in the past was that websites had to offer users a way to opt out of having cookies stored on their computer. The reason that is much more stupid is that there is no other way to store information about the user opting out than by doing it through a cookie.
You could still implement it, but it wouldn't do the user any good. Once they decide to opt out, the webserver could tell the browser to delete all cookies, and they could track the fact for the duration of the http connection. Once the connection gets closed and the user sends a request on a new connection, there will be no information in the request to let the server know, that this is the user that opted out. The information that the user had opted out was in fact deleted at the users request. Such an implementation would be stupid, but it would essentially be what would have been the outcome if previous suggestions had been implemented as suggested.
This browser header would OTOH be much more feasible to implement. Of course it isn't going to technically enforce anything. But there are enough websites that want to play by the rules, that it would still mean something.
If some browser vendors decide that it should be opt-in rather than opt-out and change the default setting in their browser, they do run the risk of making websites decide not to honer the header from those browsers.
Having the header shouldn't mean the website cannot set cookies at all. It should still be possible to set session cookies when technically required for some use case. It should also be possible to set cookies, when the user explicitly do things that would require cookies. For example if they fill in a registration form or a login dialogue, the site can set a cookie. However such a cookie should be deleted at logout time. The site should also be able to set cookies if the user decide to save preferences. But the cookie shouldn't contain any information beyond the preferences. In other words, if two users decide to set the same preferences, they should get identical cookies. And log entries on the webserver shouldn't contain anymore information from the cookie than what was used to render that request. For example if the preferences contain a language setting that applies to all pages, and a display setting that only applies to a subset of the pages, then all requests could log what language the user was using, but not what the other setting was.
All of this is just for those sites that want to play by the rules. Of course there will always be sites that won't play by the rules. But that shouldn't stop us from agreeing on an improvement for those sites that will respect such a header.
Oh yes, and your friends will not be able to see your pictures unless they download a plugin
So, I guess without that plugin the browser will not recognize the file as a picture. But how about Facebook, why would they recognize the file as a picture? I guess Facebook does not handle pictures as binary blobs that remain completely unmodified from upload until they are sent to a browser. They already scale the pictures, and I am not even sure if you can get to see it in the original resolution.
So I guess they would have to make something that will still look like a picture, and which they can decrypt after it has been scaled. If they designed an encryption with those properties, I guess it will turn out to be totally broken, and there will be an easy way to decrypt without the key.
I hope for them that hey have done the tests that can be done before enabling AAAA records for lots of users. Or that at least they plan to do so before the 8th of June.
Sending out the AAAA records cannot be rolled out in that small steps. Once they send an AAAA record to a DNS server, it is active for all users of that DNS server.
Taking just a few DNS servers is not going to be representative. And taking a small percentage of the users of each DNS server is impossible.
It sounds like you don't completely understand the difference between fragmentation at the IP level and segmentation at the TCP level.
The IPv4 header contains fields that can be used to split and reassemble any IP packet regardless of what the higher level protocol is. When a packet is fragmented the receiving host cannot use them for anything until it has received all the fragments. If one fragment is lost, the rest will be thrown away.
But TCP does not have to make use of this fragmentation at the IP level. TCP splits the data into segments of whatever number of bytes is appropriate. The TCP headers contain more information which means that each individual segment can be used as soon as it is received (assuming earlier segments arrived already). There is no need to wait for the last segment before using the first. And if one segment is lost, only that segment needs to be retransmitted. Because of this TCP usually sets the don't fragment flag and if the packet is too large, the packet is not fragmented at the sending host or an intermediate router. Instead TCP will create a smaller segment that doesn't need to be fragmented to be send to the destination.
With IPv6 all the fields are moved from the header to an option header, that routers never have to look at. The don't fragment flag is removed, as it is implicitly on, no router is allowed to fragment a packet in transit. If a packet is not fragmented by the sender, it won't be fragmented at all, and the option header can be left out.
With IPv4 and the don't fragment bit set the behaviour is almost identical to IPv6. One advantage is that with IPv6 the header fields are left out, so you don't have the problem with leaking information about amount of traffic through the IPID field.
I have said this before and I still believe the best course of action is to simply scrap IPV6 and take IPV4 and simply change the segment size from BYTES to WORDS.
Seems you didn't say it early enough or not to the right people. With your suggestion we would be starting over from where we were 15-20 years ago. That means you will need to upgrade all routers on the Internet to support your proposed protocol, and you have a couple of weeks to get it done. What makes you think that you can achieve in a couple weeks, what the people who build the Internet in the first place couldn't achieve in a decade?
Can anyone seriously really see a day when we will have more then 65535 ISP's?
The AS numbers are running out and are being extended from 16 to 32 bits. This is totally unrelated to the upgrade from IPv4 to IPv6 (except of course both are triggered by the growth of the Internet).
Basically 1% deployment of IPv6 completely flips their argument if the goal is serving the largest number of folks.
Only if that was 1% of users with only IPv6 and no way to get at an IPv4 only server. If those IPv6 users also have access to a NAT box that works 98% of the time and give them access to IPv4 only sites, then you would need 50 times more IPv6 deployment to flip the argument, and 1% would not be enough.
If there's no end-to-end 1500B MTU path for IPv4, then the traffic is going to be fragmented all day every day
Typically TCP sets the don't fragment flag on each packet. If the MTU is less, it will receive an ICMP message telling it which size to use. Unless the MTU is ridiculously small, it is better to rely on TCP segmentation instead of IP fragmentation.
Most protocols run over UDP will use smaller packets to begin with.
I sure hope no one is relying on 1500 byte MTU paths. As I recall, the most anyone can rely on is 576.
That is not exactly correct. To conform with the standard, an IPv4 implementation must support an MTU of at least 68 bytes. That is ridiculously small. If you wanted to send TCP packets without fragmentation and make use of timestamps for better reliability, you would have a total of 52 bytes of headers. That leaves enough room for 16 bytes of payload. A network with that kind of MTU makes fragmentation seem like a good idea. The size of packet that you are guaranteed the recipient can reassemble is 576 bytes. For example you could take a 548 byte packet (20 bytes IPv4 header + 528 bytes IP payload) and split it into 11 packets of 68 bytes (20 bytes header + 48 bytes of payload). That would leave you with 476 bytes of TCP payload.
If you don't have some information telling you that the recipient can handle larger packets, a conforming TCP implementation must not send packets that would be larger than 576 bytes after reassembly. But if an mss option on the SYN packet indicated larger size, you are of course allowed to send larger packets.
With IPv6 the guaranteed MTU was increased from 68 to 1280 bytes. The guaranteed reassembled packet was increased from 576 to 1500 bytes.
That makes me think that Verizon's 4G smartphones will be like their 4G data users are now - private, NATed IPv4 access and a public IPv6 address.
One company (I don't remember which one) announced that they would use IPv6 only for new phones. For domain names with only A records they would do NAT64+DNS64. This is not exactly the same as NAT from IPv4 to IPv4. There are things that work with NAT44 that will not work with NAT64. But at least most websites will work over NAT64.
I suppose for those websites that make use of whitelisting to decide who gets AAAA records, it will be a convincing argument. The reason for not just handing out to everyone is broken IPv6 connectivity, but now these networks can go and say that their IPv4 connectivity is going to be even worse. (And hopefully their IPv6 connectivity will work for more than 99.95% of their customers).
in which case the IPv4 may not have a full 1500B MTU to the end user, etc etc.
In case of NAT64, there will usually be a 1500 bytes MTU on both sides, but the NAT change the size of the packets which makes it look like you have a different MTU.
Probably the best way to solve this: If the largest sites on the internet were able to do brief periods (at different times) where they were only accessible on IPv6.
No large site is going to be accessible only over IPv6 anytime soon. They will keep IPv4 running for years to come. But instead of only accessible over IPv6 let's say accessible over both IPv4 and IPv6. This is going to happen on the 8th of June, and it will last for 24 hours. We'll see after it happens if they will want to do another coordinated trial. Hopefully after the first trial we will see the percentage of problematic connections drop from 0.05% to less than 0.01%.
Sites should probably serve ipv6 from a separate colo
A separate colo for IPv6 sounds pointless to me. Multiple colos for redundancy is a good idea if you want a high uptime. Updating only one colo at a time to support IPv6 as well also sounds sensible. Turning off IPv4 on the colos where you have turned on IPv6 doesn't serve much of a purpose yet.
to a separate domain name to work the kinks out first
Several other sites have been doing that for years. I don't know if Yahoo have done any of that. But you are not going to work all the kinks out that way. Only a very small number of interested users will visit that domain. And they will by no means be a representative sample. It may help you work out a few kinks on the server side and reveal some at the client side. But once you have worked out all the problems revealed that way, you will still have 99% of users for which you didn't test the users' setups. And 0.05% of those are currently broken, and most of those users will do nothing about it until they see that their Internet connection is completely broken. Some of those users may decide to switch to a different website that has not upgraded yet. But that will only work until that site also upgrades. This is why it is great to have a one day coordinated test because it is not long enough for many users to switch permanently to another site, and several large sites (including Yahoo) will take part in the test, so the users should get the hint, assuming they use their Internet connection that day.
This has nothing to do with Yahoo. Those users won't be able to access any other IPv6 capable website either. Hopefully most of them will be fixed around the 8th of June, where large parts of the Internet will be unreachable for them that day.
I welcome a commitment to move ahead even if it means a few people will have to fix their Internet connection. Hopefully they have an ISP that can help them, and if not, they should probably find a different ISP.
After all the mess we will have if websites remain IPv4 only will be much worse than 0.05% of users losing access temporarily until they get a working Internet connection again.
I wonder if anyone thought of forcing AAAA requests (dns IPv6 requests) for those sites only on ipv6 packets, and denying them if they are in ipv4 packets
It's not that easy. You have three different communications going on. Client to DNS resolver, DNS resolver to authoritative DNS server, and client to server. Each of those three can choose independently between IPv4 and IPv6. How the resolver communicates with the authoritative server will tell you very little about the IPv4 and IPv6 support the client has. Moreover, the result will be cached and used for other clients that may have different connectivity.
The best chances would be an extension to the DNS protocol where the resolver will tell the authoritative DNS server something about the IP of the client, and the authoritative DNS server can include some information about the scope of the reply, such that the resolver will know which clients to use the cached result for. There was some proposal at some point, but I haven't seen the details, so I don't know if it works the way I describe.
To set it up to work with IPv6 dhcp (ie the standard setup most people use with IPv4) you have to jump through 10 hoops or so.
With IPv6 you don't need to use DHCP. Autoconfig of hosts is built directly into the protocol. Sure you can still use DHCP to configure hosts with IPv6, but I really don't see any reason to complain that it is extra work to configure your system for a nonstandard setup. At least you can still do it if you absolutely want to.
Chances are the majority of users will use DHCP for IPv4 and autoconfig for IPv6 because that is what computers and routers will do by default. The main need for DHCP with IPv6 is for configuring routers. If you buy a router with good IPv6 support, it will probably do DHCP towards your ISP in order to get an IPv6 address and a prefix or two for your LAN. And then it will do router advertisements on the LAN such that computers can be configured without use of DHCP.
Some of us are either more cautious, or less well informed.
Being cautious is ok. A 10 year transition plan to ensure there is time to address any issues coming up sounded like a good plan. But what happened was that nobody wanted to make the first move. And we now have a situation where we have realized what the first hurdle is and the first large scale test to see if we have resolved that hurdle is scheduled to happen a few months after the IANA pool of IPv4 addresses run out.
All the years where almost nothing happened means that the transitioning now have to happen faster, and it will be more problematic because there won't be any free IPv4 addresses for the last part of the transitioning. If the transitioning had gone according to the plan people would be shutting down IPv4 networks now because it wouldn't be worth the hassle to run both IPv4 and IPv6. Unfortunately that isn't the situation.
For the Internet as a whole, all this cautiousness appears to be causing more problems than it prevented. I can understand why it from each individual's viewpoint seemed like the right thing to do. But from a global perspective it is turning into a disaster.
If you have information regarding implementing Security Enhanced Neighbour Discovery
I don't know more than what was mentioned in the video. I would expect that some high end switches can be configured to do filtering that will address the majority of issues, but I don't know any specific details about that either.
Slashdot Mirror
I'll tell you what I don't like about it. I don't mind them charging for an answer when both the person who asked the question, and the person who gave the answer is ok with that. On the other hand, I am not an ExpertsExchange user, and I do not think that it is ok that they charge for access to answers that I wrote.
I know there are ways to get to see the answer without paying, and that is why I know that some of the answers are nothing but a link to a webpage where I provided the answer to the question (before it was even asked on ExpertSexchange). So far I haven't decided what to do about this. I could direct the users who access my site by using a link from ExpertsExchange through an interstitial page, but that would seem like punishing the users instead. But maybe if I used the page not just to point out my opinion about that site, but to also mention free alternatives, then it may be ok. I have also considered telling ExpertsExchange to make all pages with links to my pages freely available. (If newspapers can claim it is a copyright violation to link to their news, then I should be able to make similar requirements to ExpertsExchange. But it does feel going a bit against my principles because I think linking directly to pages with relevant information is what the web is all about).
But what I dislike even more than sites charging for access to answers, that are little more than a link to my site, is those fake forums that pretend I am a user of their site. But in reality the entire content of that forum site is a ripoff of a selection of usenet groups. I'd feel much better about claiming copyright violation against such sites because they actually have copied content copyrighted by me. On the other hand, it seems a bit futile to try to go against all of those sites that way. And it may be difficult to draw a line between a legitimate webinterface for usenet, and a blatant ripoff. However, one distinguishing feature is whether the site makes it clear that it is a webinterface for usenet, or whether it pretends to be a amazingly popular webforum. Another distinguishing feature is whether it focuses on a (small) group of users that use it as their way to access usenet, or if the site simply try to attract all kinds of users from every searchengine out there, and just throw tons of ads at the users (with a little bit of copied content in between).
I don't know what blocksize ECC memory uses. It would make sense to use one line of the DRAM memory, because if you don't actually correct errors during refresh, then the probability of an uncorrectable error increases the longer a memory location has remained untouched. Without correction, you could be reading out bad data and writing it back. And the memory would be accumulating errors.
I have seen computers where one work and the other doesn't. But I'll have to admit, that most of my issues with it could be resolved by fixing the software, and no new hardware would be required.
With the laptops I currently have, the situation is as follows. My work laptop (MacBook Pro) is configured to automatically suspend to RAM and disk simultaneously. And this works flawlessly until it actually need to resume from disk at which point it crashes and reboots. My older personal laptop by default suspend to RAM and crash when resumed, but if I remember to suspend to disk it does actually resume just fine 95% of the time. My newer personal laptop by default suspend to RAM as soon as I close the screen, and it resumes just fine. I didn't try to figure out how to make it suspend to disk.
There is a couple of general issues with the suspend functionality. If storage encryption is in use, most implementations suffer from the serious flaw of keeping the key around while suspended. They make this mistake both when suspending to RAM and when suspending to disk. However I believe extracting the key from RAM requires a bit more skill than extracting it from disk.
Finally the estimate of how much battery is left is not always accurate enough to have the system automatically suspend before power runs out. And this may be the only issue on my list that would require hardware changes to fix. All the other ones are simply software bugs that need to be fixed.
Aren't you going to need this on-the-fly error correction in every system where you don't want a random bitflip to happen every once in a while? I would assume the data going between the DRAM and the SRAM in the control part of the chip would always go through some ECC logic both ways, except on those chips where it was cut out in order to reduce cost.
Indeed. The number of possible write cycles is important if you wanted to replace RAM. I'd wish we had a kind of memory with all the properties that would be important to use it as swap space. That means many write cycles, performance better than flash and hard disk (but not necessarily as fast as DRAM), and finally price and density that is closer to flash than to DRAM.
Fast and durable does have its places. Imagine if you could design a computer where you didn't have to worry about losing power for a short period of time because once the power returned, the entire contents of RAM would still be there and you could just resume where it left off. It would eliminate the need for a UPS in some places (but not in all places). And it would mean you didn't have to ensure that your laptop was suspended before battery runs out, and you don't lose what you were working on in case the battery does run out while suspended.
Not necessary. The operating system already has to assume there could be random garbage in all the memory it didn't touch. The operating system has to zero the memory before handing it to applications. And that is the case even if it was zeroed on boot. It could be a long time since the system was booted, and the memory may have been used for something in the meantime. Some operating systems keep a cache of zeroed pages that can be handed to applications as needed, others do it on demand.
If you want the hardware to be modified slightly to achieve it, then it should be completely practical. DRAM doesn't write individual cells at a time. It reads out entire lines of bits into SRAM modifies it there and writes it back. Moreover it even periodically sweeps over the lines just reading them out and writing them back to refresh them.
I don't know how long time the sweep takes, but for wiping the memory you could speed it up. The control logic have a number of outgoing lines with a binary number indicating which line of cells to read or write. Each line has a decoding unit to know when its number is up. If you added a line to select all lines simultaneously and OR that line with the output of the existing decoding unit, it sounds feasible that the control logic could in fact write the contents of the SRAM to all lines in parallel.
If this works you could wipe memory in less than a microsecond.
I have heard much more stupid suggestions on how to improve privacy. One suggestion in the past was that websites had to offer users a way to opt out of having cookies stored on their computer. The reason that is much more stupid is that there is no other way to store information about the user opting out than by doing it through a cookie.
You could still implement it, but it wouldn't do the user any good. Once they decide to opt out, the webserver could tell the browser to delete all cookies, and they could track the fact for the duration of the http connection. Once the connection gets closed and the user sends a request on a new connection, there will be no information in the request to let the server know, that this is the user that opted out. The information that the user had opted out was in fact deleted at the users request. Such an implementation would be stupid, but it would essentially be what would have been the outcome if previous suggestions had been implemented as suggested.
This browser header would OTOH be much more feasible to implement. Of course it isn't going to technically enforce anything. But there are enough websites that want to play by the rules, that it would still mean something.
If some browser vendors decide that it should be opt-in rather than opt-out and change the default setting in their browser, they do run the risk of making websites decide not to honer the header from those browsers.
Having the header shouldn't mean the website cannot set cookies at all. It should still be possible to set session cookies when technically required for some use case. It should also be possible to set cookies, when the user explicitly do things that would require cookies. For example if they fill in a registration form or a login dialogue, the site can set a cookie. However such a cookie should be deleted at logout time. The site should also be able to set cookies if the user decide to save preferences. But the cookie shouldn't contain any information beyond the preferences. In other words, if two users decide to set the same preferences, they should get identical cookies. And log entries on the webserver shouldn't contain anymore information from the cookie than what was used to render that request. For example if the preferences contain a language setting that applies to all pages, and a display setting that only applies to a subset of the pages, then all requests could log what language the user was using, but not what the other setting was.
All of this is just for those sites that want to play by the rules. Of course there will always be sites that won't play by the rules. But that shouldn't stop us from agreeing on an improvement for those sites that will respect such a header.
So, I guess without that plugin the browser will not recognize the file as a picture. But how about Facebook, why would they recognize the file as a picture? I guess Facebook does not handle pictures as binary blobs that remain completely unmodified from upload until they are sent to a browser. They already scale the pictures, and I am not even sure if you can get to see it in the original resolution.
So I guess they would have to make something that will still look like a picture, and which they can decrypt after it has been scaled. If they designed an encryption with those properties, I guess it will turn out to be totally broken, and there will be an easy way to decrypt without the key.
I hope for them that hey have done the tests that can be done before enabling AAAA records for lots of users. Or that at least they plan to do so before the 8th of June.
Sending out the AAAA records cannot be rolled out in that small steps. Once they send an AAAA record to a DNS server, it is active for all users of that DNS server.
Taking just a few DNS servers is not going to be representative. And taking a small percentage of the users of each DNS server is impossible.
It sounds like you don't completely understand the difference between fragmentation at the IP level and segmentation at the TCP level.
The IPv4 header contains fields that can be used to split and reassemble any IP packet regardless of what the higher level protocol is. When a packet is fragmented the receiving host cannot use them for anything until it has received all the fragments. If one fragment is lost, the rest will be thrown away.
But TCP does not have to make use of this fragmentation at the IP level. TCP splits the data into segments of whatever number of bytes is appropriate. The TCP headers contain more information which means that each individual segment can be used as soon as it is received (assuming earlier segments arrived already). There is no need to wait for the last segment before using the first. And if one segment is lost, only that segment needs to be retransmitted. Because of this TCP usually sets the don't fragment flag and if the packet is too large, the packet is not fragmented at the sending host or an intermediate router. Instead TCP will create a smaller segment that doesn't need to be fragmented to be send to the destination.
With IPv6 all the fields are moved from the header to an option header, that routers never have to look at. The don't fragment flag is removed, as it is implicitly on, no router is allowed to fragment a packet in transit. If a packet is not fragmented by the sender, it won't be fragmented at all, and the option header can be left out.
With IPv4 and the don't fragment bit set the behaviour is almost identical to IPv6. One advantage is that with IPv6 the header fields are left out, so you don't have the problem with leaking information about amount of traffic through the IPID field.
You can try http://test-ipv6.com/ or http://ds.test-ipv6.com/
Seems you didn't say it early enough or not to the right people. With your suggestion we would be starting over from where we were 15-20 years ago. That means you will need to upgrade all routers on the Internet to support your proposed protocol, and you have a couple of weeks to get it done. What makes you think that you can achieve in a couple weeks, what the people who build the Internet in the first place couldn't achieve in a decade?
The AS numbers are running out and are being extended from 16 to 32 bits. This is totally unrelated to the upgrade from IPv4 to IPv6 (except of course both are triggered by the growth of the Internet).
Only if that was 1% of users with only IPv6 and no way to get at an IPv4 only server. If those IPv6 users also have access to a NAT box that works 98% of the time and give them access to IPv4 only sites, then you would need 50 times more IPv6 deployment to flip the argument, and 1% would not be enough.
Maybe they did that already. This could be where they got the 0.05% number from.
Typically TCP sets the don't fragment flag on each packet. If the MTU is less, it will receive an ICMP message telling it which size to use. Unless the MTU is ridiculously small, it is better to rely on TCP segmentation instead of IP fragmentation.
Most protocols run over UDP will use smaller packets to begin with.
That is not exactly correct. To conform with the standard, an IPv4 implementation must support an MTU of at least 68 bytes. That is ridiculously small. If you wanted to send TCP packets without fragmentation and make use of timestamps for better reliability, you would have a total of 52 bytes of headers. That leaves enough room for 16 bytes of payload. A network with that kind of MTU makes fragmentation seem like a good idea. The size of packet that you are guaranteed the recipient can reassemble is 576 bytes. For example you could take a 548 byte packet (20 bytes IPv4 header + 528 bytes IP payload) and split it into 11 packets of 68 bytes (20 bytes header + 48 bytes of payload). That would leave you with 476 bytes of TCP payload.
If you don't have some information telling you that the recipient can handle larger packets, a conforming TCP implementation must not send packets that would be larger than 576 bytes after reassembly. But if an mss option on the SYN packet indicated larger size, you are of course allowed to send larger packets.
With IPv6 the guaranteed MTU was increased from 68 to 1280 bytes. The guaranteed reassembled packet was increased from 576 to 1500 bytes.
One company (I don't remember which one) announced that they would use IPv6 only for new phones. For domain names with only A records they would do NAT64+DNS64. This is not exactly the same as NAT from IPv4 to IPv4. There are things that work with NAT44 that will not work with NAT64. But at least most websites will work over NAT64.
I suppose for those websites that make use of whitelisting to decide who gets AAAA records, it will be a convincing argument. The reason for not just handing out to everyone is broken IPv6 connectivity, but now these networks can go and say that their IPv4 connectivity is going to be even worse. (And hopefully their IPv6 connectivity will work for more than 99.95% of their customers).
In case of NAT64, there will usually be a 1500 bytes MTU on both sides, but the NAT change the size of the packets which makes it look like you have a different MTU.
Yes. Experimental support defined in RFC 5006. In RFC 6106 it was put on the standards track.
No large site is going to be accessible only over IPv6 anytime soon. They will keep IPv4 running for years to come. But instead of only accessible over IPv6 let's say accessible over both IPv4 and IPv6. This is going to happen on the 8th of June, and it will last for 24 hours. We'll see after it happens if they will want to do another coordinated trial. Hopefully after the first trial we will see the percentage of problematic connections drop from 0.05% to less than 0.01%.
A separate colo for IPv6 sounds pointless to me. Multiple colos for redundancy is a good idea if you want a high uptime. Updating only one colo at a time to support IPv6 as well also sounds sensible. Turning off IPv4 on the colos where you have turned on IPv6 doesn't serve much of a purpose yet.
Several other sites have been doing that for years. I don't know if Yahoo have done any of that. But you are not going to work all the kinks out that way. Only a very small number of interested users will visit that domain. And they will by no means be a representative sample. It may help you work out a few kinks on the server side and reveal some at the client side. But once you have worked out all the problems revealed that way, you will still have 99% of users for which you didn't test the users' setups. And 0.05% of those are currently broken, and most of those users will do nothing about it until they see that their Internet connection is completely broken. Some of those users may decide to switch to a different website that has not upgraded yet. But that will only work until that site also upgrades. This is why it is great to have a one day coordinated test because it is not long enough for many users to switch permanently to another site, and several large sites (including Yahoo) will take part in the test, so the users should get the hint, assuming they use their Internet connection that day.
This has nothing to do with Yahoo. Those users won't be able to access any other IPv6 capable website either. Hopefully most of them will be fixed around the 8th of June, where large parts of the Internet will be unreachable for them that day.
I welcome a commitment to move ahead even if it means a few people will have to fix their Internet connection. Hopefully they have an ISP that can help them, and if not, they should probably find a different ISP.
After all the mess we will have if websites remain IPv4 only will be much worse than 0.05% of users losing access temporarily until they get a working Internet connection again.
It's not that easy. You have three different communications going on. Client to DNS resolver, DNS resolver to authoritative DNS server, and client to server. Each of those three can choose independently between IPv4 and IPv6. How the resolver communicates with the authoritative server will tell you very little about the IPv4 and IPv6 support the client has. Moreover, the result will be cached and used for other clients that may have different connectivity.
The best chances would be an extension to the DNS protocol where the resolver will tell the authoritative DNS server something about the IP of the client, and the authoritative DNS server can include some information about the scope of the reply, such that the resolver will know which clients to use the cached result for. There was some proposal at some point, but I haven't seen the details, so I don't know if it works the way I describe.
With IPv6 you don't need to use DHCP. Autoconfig of hosts is built directly into the protocol. Sure you can still use DHCP to configure hosts with IPv6, but I really don't see any reason to complain that it is extra work to configure your system for a nonstandard setup. At least you can still do it if you absolutely want to.
Chances are the majority of users will use DHCP for IPv4 and autoconfig for IPv6 because that is what computers and routers will do by default. The main need for DHCP with IPv6 is for configuring routers. If you buy a router with good IPv6 support, it will probably do DHCP towards your ISP in order to get an IPv6 address and a prefix or two for your LAN. And then it will do router advertisements on the LAN such that computers can be configured without use of DHCP.
Being cautious is ok. A 10 year transition plan to ensure there is time to address any issues coming up sounded like a good plan. But what happened was that nobody wanted to make the first move. And we now have a situation where we have realized what the first hurdle is and the first large scale test to see if we have resolved that hurdle is scheduled to happen a few months after the IANA pool of IPv4 addresses run out.
All the years where almost nothing happened means that the transitioning now have to happen faster, and it will be more problematic because there won't be any free IPv4 addresses for the last part of the transitioning. If the transitioning had gone according to the plan people would be shutting down IPv4 networks now because it wouldn't be worth the hassle to run both IPv4 and IPv6. Unfortunately that isn't the situation.
For the Internet as a whole, all this cautiousness appears to be causing more problems than it prevented. I can understand why it from each individual's viewpoint seemed like the right thing to do. But from a global perspective it is turning into a disaster.
I don't know more than what was mentioned in the video. I would expect that some high end switches can be configured to do filtering that will address the majority of issues, but I don't know any specific details about that either.