they used to (ab)use customers on open internet connections to provide this service but nowadays I belive they provide it from their own servers
Not sure what they are doing these days. Their old scheme was a major contributing factor in a huge Skype outage a few years back. As far as I recall, they needed a bunch of servers at Amazon in order to get Skype back online. That outage might never have happened, if IPv6 had been deployed when it should have been.
And there are millions of packets going by on the Internet. Just think, if every other packet were concatenated on the previous one, there would be half as many packets, and that would double the capacity of the routers.
This only helps as long as the processing power on the router is the bottleneck. As soon as packets are large enough, the actually link bandwidth will be the bottleneck. At that point fewer larger packets will not give you more throughput.
As links become faster the optimal packet size will also increase. There is a huge difference between dialup and 100Gbit/s fiber. You wouldn't want the same size of packets on both kinds of link. A 1500 byte packet would block a dialup link for long enough to cause a measurable latency increase for any small packet you might want to send through at higher priority. You don't want packets that large on dialup. But on 100Gbit/s fiber such a packet size would mean millions of packets per second. You'd want larger packets, such that you don't need to handle millions of packets per second.
But what about those packets, which go over links of different types? With IPv4 they could be large as they were sent and be split into smaller fragments on their way to the destination, and then be reassembled at their final destination. But having this work done by routers on the path adds to the processing cost for that router, and that processing cost is what we want to reduce in the first place. For that reason this was changed in IPv6. Routers no longer fragment packets in transit. A packet is the same size all the way from the source to the destination.
Assembling multiple fragments into one packet is even more work and was never done by intermediate routers. (Some firewalls might do it before deciding whether to forward or drop the packet, but that was never intended by the standard.) Grouping unrelated packets would be even more difficult. And as long as it is only done end-to-end, it can only be done if they have the same source and destination anyway. There is no standard for doing this.
But for traffic that would get segmented by TCP or fragmented by IP, we really do want to have the packets on the wire get larger as link speeds increase. In fact the maximum size was increased between IPv4 and IPv6. It used to be 64KB but has been increased to 4GB. Hardware that would allow us to benefit from that increase is still difficult to come by (if it even exists), but IPv6 is designed to be usable in many years, so it makes sense to support larger packets.
Yeah, then we came up with CIDR. Then we widely implemented NAT as a stopgap.
CIDR was a great stopgap. NAT was not.
Without CIDR the addresses would have run out faster than any solution could have been implemented. CIDR was not that big a change, so it didn't break lots of stuff. And it slowed down the consumption of addresses a lot. If a decent effort had been put into upgrading to IPv6, it could have been completed before addresses ran out, even if CIDR had been the only stopgap measure, and NAT had never been invented.
But NAT got widely deployed. Not because real scarcity of IPv4 addresses, but rather because of an artificial scarcity. ISPs were charging for IP addresses, so with NAT already available, private users used that to avoid paying extra. It did slow down IPv4 consumption so much, that ISPs decided not to work on deploying IPv6. But a major reason for the deployment not happening faster actually was that there was no competitive advantage.
The ISP which deploys IPv6 has some expenses in doing so. If they decide to save that money, they are causing a problem. But the problem they cause affects the entire industry, so it was not a competitive disadvantage. Moreover the lack of IPv6 deployment is now causing more problems for newcomers than it is for those established companies, who were responsible for the problem in the first place. And this is the real reason we have such a mess today.
Rationing of IPv4 addresses was a great idea. It just happened way too late. Rationing once you have consumed 98% of a resource is not solving the main problem. The 1024 IPv4 addresses an ISP can get if they start deploying IPv6 is not that great an incentive.
At the time CIDR was introduced a rationing policy should have been agreed upon. As soon as IPv6 implementations were reasonably mature, but not widely deployed, rationing should have been applied to keep the base of IPv4 only systems constant. At that point ISPs should only have been able to get new IPv4 addresses for use in dual-stack deployments. If they used the newly allocated IPv4 addresses for IPv4 only deployments, they should have received no more IPv4 addresses until they had converted enough IPv4 only systems to dual stack.
A proper rationing policy would have ensured by the time IPv4 addresses ran out, there would be at least as many dual stack deployments as IPv4 only deployments. That would make IPv6 only look much more viable, and it wouldn't take a lot of IPv6 only systems to make dual stack look preferable to IPv4 only, if dual stack was proven to work in practice.
It is too late to implement such a policy now. So we will have to find another way out of this mess. It was clear already a decade ago, that there simply didn't exist the right economic incentives for ISPs to deploy IPv6. And nobody in place to implement the needed policy, had the balls to do it. That IPv4 addresses ran out without IPv6 having reached a significant deployment should not have come as a surprise to anybody. That ISPs still believe IPv4 only is the best strategy even now, is however a bit surprising, and quite scary.
NAT was part of the reason it took such a long time to reach the point we are at now. And what good has it done us? It delayed the inevitable. But that extra time was not used to make us more prepared for it, as such we didn't get any benefit from NAT, which we can use to ease the deployment of IPv6. Also the delay has meant the network is now larger, which means more work and more expensive to upgrade, than it would have been, had it happened earlier. NAT also made the network more complicated, and many of the blockers in deploying IPv6 are due to problems caused by NAT. Moreover many people have gotten so used to NAT, they don't know how the Internet was supposed to work. And now they don't want IPv6 because it doesn't look like what they are used to. Lots of effort has been put into developing workarounds for the problems introduced by NAT. And none of them work great. All of that wasted effort would have been much better spent on getting IPv6 deployed in the first place.
There is just no way anyone isn't at least a avid slashdot reader in terms of techniess is going to be able to be on an ipv6 only endpoint
You won't see many IPv6 only users on slashdot either. I'm wondering if I should change my signature to read "slashdot is part of the problem" until they eventually set up AAAA records for slashdot.
You could have a DNS server that generates synthetic AAAA records from the ipv4 A records and predefined prefix that routes to the NAT.
64:ff9b::/96 is allocated for exactly that purpose. And BIND has support for synthesising the AAAA records. But I don't see much benefit from such a deployment compared to dual stack plus CGN.
Its going to make inspects and higher level protocol address rewrites pretty complex for the gateway. Think something like h.323 with the host address. You can't just swap out 6 bytes worth of src/port you going to have to completely re-craft that packet's content.
Exactly, that is a real challenge. And for that reason I think CGN + dual stack is more viable in some situations. Deploying CGN without dual stack is just screwing over the customers.
Your issue should only occur for a site that claims to be available on IPv6 and isn't.
There are plenty of those sites around. But what you see even more are sites, which are available on IPv6, but are quite unreliable on IPv6. A couple of high profile examples include YouTube and facebook, which are much more reliable if you are on an IPv4 only connection, than if you have dual stack.
One of the blocking factors that kept websites from deploying IPv6 in the first place was a problem on the client side with clients which thought they had IPv6 support, but in reality did not. This is similar to the problem you describe, but is different. An ISP should of course not deploy IPv6 to their customers if they aren't going to have real connectivity to the IPv6 backbone. But as RFC 6598 addresses start seeing more use, there will be routes thinking they can use 2002:6440::/26 6to4 address space. Those clients will then think they have IPv6 connectivity, but won't be able to reach dual stack sites.
An ISP can actually avoid that particular problem by deploying native IPv6 to their customers. Once there is native IPv6, the routers won't bring up 6to4. That way you can avoid 6to4, which has been broken by RFC 6598.
IANA has recently reserved the IP block 100.64.0.0/10 for use with carrier grade NAT.
That's interesting. I didn't know about that block. I'll keep that in mind as I might get involved with deployments, where this is applicable. I looked up the relevant RFC, which is RFC 6598. I find it interesting that this was taken out of ARIN address space. With ARIN being next in line to run out, this block must have accelerated depletion for ARIN.
That there is a/10 allocated for the purpose doesn't necessarily mean there will be millions of users behind a single CGN. A medium sized ISP could use this/10 to assign one address to each customer without having duplicated addresses within their own network, even if they plan to deploy multiple CGN devices to service their customers. That way customers of that ISP can communicate with each other as well as the ISPs own servers without going through CGN. It can also make management easier.
I am curious what this means for usage of 2002:6440::/26 address space. Things could get interested. This is briefly covered in section 5.2.6 of the RFC.
More likely they'll just insert ads directly into the video stream. Sending ads as a separate video stream makes them quite easy to remove. But no doubt Google would be able to produce a new stream containing both ad and content. That won't stop downloading the video, but the downloaded version would include the ad.
Any artificial limitation, which puts somebody else's economic interests ahead of the interests of the owner of the device, should not have been legal in the first place.
A digital camera, which cannot store more than 30 pictures on a 128MB storage card when using the best quality setting is a limitation which exists for a good technical reason. Such a limitation is not artificial, and thus shouldn't be outlawed. But a digital camera that can only take panorama photos as long as they are stored on a storage card bought from the same vendor and not if the storage card was bought from a different vendor is an artificial limitation, which does not benefit the owner of the camera in any way. It must surely have been a little bit of extra work to implement the limitation in the first place, which is what characterizes artificial limitations.
Limitations which are there for safety reasons or to improve durability of the device are fine. For example storage media have extra capacity to compensate for imperfections in the media. That the logical capacity is less than the physical capacity is in the owner's interest, because otherwise the lifetime of the device would be significantly reduced. (It is also in the vendor's interest in order to reduce RMA cases. In some countries vendor's are subject to a minimum two year warranty.)
Unless it's something so easy to crack that you can be sure that it'll get cracked, but then, you are probably receiving several login attempts with those passwords already.
You could use a difficult to guess, but plausibly looking username like for example trillyps658. Then combine that with an easy to guess password like for example password12345. The username would be stored in plaintext in the database, the password would be salted and hashed like the rest of the database, but could be one of the first thousand passwords being attempted.
In that case, what you are detecting is really that the usernames are leaked and not the passwords. But if the passwords are too difficult to break, you may never learn, that the database has been leaked. You could also let the database contain email addresses and look for any email sent to some of those addresses.
You can only achieve that with a Caesar cipher, if the alphabet size is even. They split the English alphabet into two groups of 21 and 5 letters, which are not even numbers. If they had rotated the 20 consonants by 10 positions and the 6 vowels by 3 positions, it would have worked.
I get behind the company who best supports their hardware on Linux, regardless of if the driver is open or closed source... I just want it to work dammit
The only way to get hardware which "just works" with Linux is if the driver is in the mainline kernel. And to be in the mainline kernel it has to be open source. There is no such thing as a closed source driver which "just works", because part of the requirement for earning that label is that it also works after kernel interfaces have been changed in a way, which require a recompile of the driver.
If a piece of hardware "just works", I can download the source from kernel.org, compile it and then have that hardware work. Failing that, it does not "just work".
It looks like HTTP 2.0 will require a unique IP address for each domain name.
I hope this will be true. I dislike all the workarounds applied to stretch the supply of IPv4 addresses, and I dislike name based vhosts. I'd like to see HTTP 2.0 make both of those go away, and replace it with proper IPv6 setups.
I'm guessing IPv6 eliminates any need to share IP addresses? or is there remaining technical reasons to do so?
There are technical reasons why you might want to share an IPv6 address between multiple websites. But those technical reasons can be addressed.
If we assume a webserver is hosting 1200 domains, what would happen if it was assigned a different IPv6 address for each of those domains? The answer depend on which technical solution you choose in order to do that.
The typical approach is that all of those IPv6 addresses are assigned out of the prefix on the link between the webserver and the router. Being on link, that means the router needs to perform neighbor discovery separately for each of those IPv6 addresses. The extra neighbor discovery traffic caused by this is not really a big deal, neither is the 0.1ms of extra latency when establishing a connection. But the router needs to store those entries in the neighbor table. If that table is implemented using CAM hardware for faster forwarding, it may have limited capacity.
So consuming CAM resources on the router is one possible technical reason why you might want to avoid having so many addresses.
There is a simple solution to that problem. Just use a routed prefix instead of the link prefix. If you route a prefix to the webserver, then the router just needs one routing table entry for that server instead of 1200 neighbor entries. Though a routing table entry may be more costly than one neighbor table entry, it is still cheaper than 100s of neighbor table entries.
I know of VPS providers, which don't want to assign routed prefixes to their customers. They might not yet have realized, that assigning routed prefixes can help saving resources for the provider.
Would assigning a separate routed/64 to every VPS be wasting too many IPv6 addresses? Not really, there is no way we are going to run out of/64s to assign from, as long as we are constrained to one solar system. If you really wanted to, you could make the link prefix/124 and only use a/64 for the routed prefix.
With the routed prefix in place for the webserver, the only place there could still be reasons for wanting to share an IPv6 address among multiple domains, would be in the software running on the server itself.
First of all, you'd typically need to tell the IPv6 stack in your kernel about each and every IPv6 address you want to use as a local IPv6 address of the server itself. If you wanted to use separate IPv6 addresses for each domain, you'd much rather be able to tell the kernel that you want it to treat an entire prefix like a/116 as local addresses for the server, and then allow the webserver to tell the kernel it want to bind a socket to say a/117 prefix rather than individual IPv6 addresses. I have no doubt those are features we will see in the future, if they haven't already been implemented by some kernels.
The lack of those features don't prevent you from actually assigning multiple addresses to your webserver. But the algorithms used by the kernel might not be tuned for this sort of usage. I wouldn't be surprised to hear about kernels, where CPU consumption is linear in the number of IPv6 addresses you have assigned. That could mean that the time it takes for the kernel to find out if a packet is meant for this machine goes up by a factor of 1200, potentially slowing your system to a crawl. And just configuring those addresses in the first place could take a while, as by each address you assign the CPU time needed to verify if it is new, goes up.
But a proper configuration with a routed prefix is possible today and will allow this to be done without wasting router resources, and after that it is just a minor tweak of the kernel on the server to support it efficiently. With those two in place, there are benefits to be had from assigning separate IPv6 addresses to each domain.
As a firewall administrator, unless I am being attacked from a specific IP, I will block hostname in preference to IP precisely because of this sort of problem.
That statement makes no sense to me. The only sort of attack mentioned in the story is the DoS attack performed by another network blocking legitimate packets. There is no additional blocking that the server administrator could perform to solve that. And even if the server was under some other kind of attack (such as flooding), the only hostnames potentially involved are those assigned to the server itself. Blocking those hostnames, just means you are DoSing your own server. The attacker doesn't have a hostname, you can block them on.
And all of this desire for security is based on your suspicion that an eavesdropper could glean information that would harm you from just your mouse movements
You are assuming cryptography is all about protecting the confidentiality of data. That is a common mistake to make. But in this particular case I did point out in my initial post, that authenticity is also important. In fact in most cases authenticity and integrity of the data is more important than confidentiality.
Instead of asking what you can learn from observing mouse movements, consider what you can do if you control mouse movements. Most UIs have buttons located in predictable positions. Click on some of those to take control over the computer. All you need to be able to do is to navigate a browser to a malicious website and click yes on a few confirmations that you want to download some executable and run it. Sounds like a quite feasible task to achieve using a mouse.
Next ask if the receiving end of the wireless connection actually cares if it is a mouse or a keyboard. If it accepts keyboard input as well, then the attack is much easier to carry out, even if I didn't use any wireless keyboard myself.
As for the confidentiality, mouse movements used to be the primary source of randomness for use in cryptographic protocols. That certainly adds to the risk from somebody being able to observe all mouse movements.
If your data or user base can be easily partitioned
If you can get away with low consistency semantics
I agree, those properties make scalability much easier. There is another possibility, which is if your data is mostly static. If you can simply copy your data to a bunch of servers and be done with it, then scalability is easy.
The real killer is if you have strong consistency requirements, and you have users worldwide, and data cannot be partitioned since users around the world need to read and modify the same data. If all of those are present you will be constrained by the speed of light, and putting all the smartest engineers in the world on one project won't increase the speed of light. You'll end up either relaxing the consistency requirements, artificially partitioning data, or increasing end user latency.
This sounds very much like premature optimization. You may end up designing a very scalable application and have the project fail due to too few users. If the actual number of users turn out to be an order of magnitude less than what you can handle on a single host, then all that scalability work was wasted. I think you have better chance of success with a quick proof of concept, which isn't very scalable.
It is ok to think about scalability before you have the users. But don't waste time implementing the scalable solution for a non-existing user-base.
only works when someone explains the non-existent mechanism by which ONLY laevo-rotary DNA molecules were selected . . . because any random assembly not only has the molecule as quickly disassembled but also randomly assembles an equal number of laevo-rotary and dextra-rotary DNA molecules. The latter are not only useless but dangerous to life.
The probability for a DNA molecule to appear without having used a pre-existing DNA molecule as template is tiny. Maybe it has only happened once in the entire lifetime of the Earth. In that case the orientation is completely random. It would be 50/50 for one orientation or the other. In that case if we ever find DNA based life elsewhere, the orientation of DNA molecules can give hints as to whether life has evolved independently or spread from a common origin.
It may be the probability is higher, and DNA created from scratch has happened more than once in the lifetime of the Earth. But if hundreds of years passed between the first two times it happens, it could be that life had already spread across the entire planet in the meantime. In that case the second DNA molecule could have caused some havoc in the area where it appeared, but eventually life around it adopted enough to wipe out the DNA molecule, that did not fit in.
Maybe both variants existed for some time, but during the evolution of life, one variant got extinct.
On my desktop computer I got a keyboard with a USB hub. A cable between keyboard and mouse is slightly less annoying than a cable from the mouse to the computer. On my laptop I am just using a trackpad. With training I have gotten more used to trackpads, and when I am travelling with my laptop, I often use it without access to a flat surface where I can put the mouse.
I'd still like a wireless mouse with strong cryptography and key exchange while it is charging. I think it would be feasible to use a one-time pad along with a provably secure message authentication code.
does this sound like the perfect motivation for governments to encourage IPv6 adoption?
I for one never liked name based vhosts. I have started moving my own domains to IP based vhosts on IPv6. I still have one IPv4 address with name based vhosts for those users who don't have IPv6 yet. Configuring a vhost such that it was name based when accessed over IPv4 and IP based when accessed over IPv6 was slightly tricky. But I got it working.
I do like the idea of using this as an argument for deploying IPv6. Even though there are plenty of arguments for IPv6 already that doesn't stop some people from denying there is any need at all. So to me every argument I can find for deploying IPv6 is seen as a good thing. The more arguments we have, the harder it gets to deny the need for IPv6.
So the way it would have worked would be as follows. Hosting provider has one IPv4 address shared between many vhosts, but each vhost has their own IPv6 address. If one vhost is to be blocked for hosting illegal content, one IPv4 address and one IPv6 address can be blocked. If a user tries IPv4 first and gets a connection reset, their browser would switch to IPv6.
Then we can turn the story around and say MFU should have hosted on dual stack, then they wouldn't have been blocked. The opponents of IPv6 deployment will have many arguments to pull up, but I have an answer ready for each of them. They say: "But the users don't have IPv6, so they won't be able to reach the site anyway", and I say: "If those users had choosen an ISP with IPv6 support, they would have been able to reach the site". They say: "But there isn't any ISP with IPv6 support in that area", and I say: "If the ISP hasn't deployed IPv6, then they cannot justify IP based blocking, and they must instead route traffic to that IP through a router capable of doing DPI to only block the forbidden host-name".
Of course none of this is truly great arguments, because it is sort of accepting censorship. Even if you can target only a single domain, it is still censorship. And in case a domain contains both legal and illegal pages, and the domain uses https, then blocking without collateral damage is not technically possible.
Did you miss that this block is on one IP address?
No.
Should there be packet filtering at that level?
No.
If you can implement blocking which only blocks content found to be illegal by a court of law, then that is fine. But accepting any collateral damage and accepting any blocking without the content being found illegal by a court of law is just wrong. What I am saying is, stop doing filtering, and go for the root of the problem.
But we can know that the fact that YOU personally don't know what the content was isn't really the largest problem with blocking things.
What makes you think I am special? There are billions of people who don't know either. If all of them just assume it must have been bad enough to justify this amount of collateral damage, then that is a free pass for those who want to apply censorship.
I don't believe that there could exist content so bad, that simply seeing it could be worse than living in a society of censorship.
If there's 1200 sites sharing that IP address, but they block all of them based on a single complaint, these fall into the category of collateral damage.
I guess a major part of the problem might be, that there is no penalty for blocking too much. If there is a penalty for blocking too little but none for blocking too much, then there is little incentive to do accurate filtering. A discussion about whether blocking would have been appropriate in this case, had it been more accurately targeted, seems pointless, since we don't even know what content triggered the blocking. And that may actually be the largest problem with this sort of blocking.
Some do see it as a benefit though. How often have some country blocked the worlds largest sites on the excuse that one page on each site is offending their religion. The more coarse grained your filtering is, the easier it is to conceal what you were really aiming to censor and the easier it is to find a plausible excuse for applying the filter in the first place. A civilized country shouldn't accept censorship, and especially not when it comes with such collateral damage. I don't believe there exist a problem in this world, for which censorship is the best solution.
Google does delete stuff (at least from our view...who can say what they really do behind the scenes).
I could say, because in the past I have been working on the team responsible for making backup copies of Gmail on tape. But I think the underlying storage system has been replaced since I worked on it. But a few of the key points haven't changed.
Once a user delete a message it does become inaccessible to that user. But it doesn't mean that all copies will be gone instantly. Having all copies be gone instantly would completely defy the purpose of having backup copies in the first place. The point of backups is that you can get back stuff, which you have accidentally deleted.
You could design a system where you could guarantee that the last copy was deleted exactly x days after the user hit the delete button. But designing for such an exact guarantee would require more resources. Instead you could have a system where the guarantee was that the last copy would be deleted between x and 3x days after the user hit the delete button. This flexibility allows for a simpler and cheaper design. I don't know what sort of range Gmail operates with these days, neither if the number is published.
For a data transfer such as the one we are talking about here none of those deleted mails should be part of the transfer. If they were, that would sound like a mistake on Google's part, but I don't think that is what happened. I think your explanation sounds more likely.
If Sky had said they wanted any email deleted in the last x days to be restored from backup to be part of the transfer, then that would have sounded like a completely unreasonable request to a lot of people. I think Google would have argued, that it would not be in the users' interest to do so.
Then they were not correctly implementing the protocol.
As long as the message is no longer visible to POP clients, they are indeed following the protocol. The POP protocol does not require the server to find every copy of the message in existence across all servers on the Internet and delete them. If downloading the mail to your computer caused the copy accessible through the webinterface to get deleted, people would be screaming about data loss. Gmail offers four possible configurations on what happens to the copy in the webinterface when the copy accessible through POP is deleted. It looks like the default is to do nothing, which treats them as independent copies.
I'm sure Sky could have gotten a different default setting for their own customers, if they had asked for it. But why would they have asked for a default setting, which would cause data loss for those users, who did not fully understand the system, they were working with.
POP is an outdated protocol, which was not designed for a world where users want to access their email on multiple devices. Rather than telling users they had to upgrade to IMAP or implementing POP in a way that was useless to most of the users, Google decided to implement something that was working well for the users.
Slashdot Mirror
Not sure what they are doing these days. Their old scheme was a major contributing factor in a huge Skype outage a few years back. As far as I recall, they needed a bunch of servers at Amazon in order to get Skype back online. That outage might never have happened, if IPv6 had been deployed when it should have been.
This only helps as long as the processing power on the router is the bottleneck. As soon as packets are large enough, the actually link bandwidth will be the bottleneck. At that point fewer larger packets will not give you more throughput.
As links become faster the optimal packet size will also increase. There is a huge difference between dialup and 100Gbit/s fiber. You wouldn't want the same size of packets on both kinds of link. A 1500 byte packet would block a dialup link for long enough to cause a measurable latency increase for any small packet you might want to send through at higher priority. You don't want packets that large on dialup. But on 100Gbit/s fiber such a packet size would mean millions of packets per second. You'd want larger packets, such that you don't need to handle millions of packets per second.
But what about those packets, which go over links of different types? With IPv4 they could be large as they were sent and be split into smaller fragments on their way to the destination, and then be reassembled at their final destination. But having this work done by routers on the path adds to the processing cost for that router, and that processing cost is what we want to reduce in the first place. For that reason this was changed in IPv6. Routers no longer fragment packets in transit. A packet is the same size all the way from the source to the destination.
Assembling multiple fragments into one packet is even more work and was never done by intermediate routers. (Some firewalls might do it before deciding whether to forward or drop the packet, but that was never intended by the standard.) Grouping unrelated packets would be even more difficult. And as long as it is only done end-to-end, it can only be done if they have the same source and destination anyway. There is no standard for doing this.
But for traffic that would get segmented by TCP or fragmented by IP, we really do want to have the packets on the wire get larger as link speeds increase. In fact the maximum size was increased between IPv4 and IPv6. It used to be 64KB but has been increased to 4GB. Hardware that would allow us to benefit from that increase is still difficult to come by (if it even exists), but IPv6 is designed to be usable in many years, so it makes sense to support larger packets.
CIDR was a great stopgap. NAT was not.
Without CIDR the addresses would have run out faster than any solution could have been implemented. CIDR was not that big a change, so it didn't break lots of stuff. And it slowed down the consumption of addresses a lot. If a decent effort had been put into upgrading to IPv6, it could have been completed before addresses ran out, even if CIDR had been the only stopgap measure, and NAT had never been invented.
But NAT got widely deployed. Not because real scarcity of IPv4 addresses, but rather because of an artificial scarcity. ISPs were charging for IP addresses, so with NAT already available, private users used that to avoid paying extra. It did slow down IPv4 consumption so much, that ISPs decided not to work on deploying IPv6. But a major reason for the deployment not happening faster actually was that there was no competitive advantage.
The ISP which deploys IPv6 has some expenses in doing so. If they decide to save that money, they are causing a problem. But the problem they cause affects the entire industry, so it was not a competitive disadvantage. Moreover the lack of IPv6 deployment is now causing more problems for newcomers than it is for those established companies, who were responsible for the problem in the first place. And this is the real reason we have such a mess today.
Rationing of IPv4 addresses was a great idea. It just happened way too late. Rationing once you have consumed 98% of a resource is not solving the main problem. The 1024 IPv4 addresses an ISP can get if they start deploying IPv6 is not that great an incentive.
At the time CIDR was introduced a rationing policy should have been agreed upon. As soon as IPv6 implementations were reasonably mature, but not widely deployed, rationing should have been applied to keep the base of IPv4 only systems constant. At that point ISPs should only have been able to get new IPv4 addresses for use in dual-stack deployments. If they used the newly allocated IPv4 addresses for IPv4 only deployments, they should have received no more IPv4 addresses until they had converted enough IPv4 only systems to dual stack.
A proper rationing policy would have ensured by the time IPv4 addresses ran out, there would be at least as many dual stack deployments as IPv4 only deployments. That would make IPv6 only look much more viable, and it wouldn't take a lot of IPv6 only systems to make dual stack look preferable to IPv4 only, if dual stack was proven to work in practice.
It is too late to implement such a policy now. So we will have to find another way out of this mess. It was clear already a decade ago, that there simply didn't exist the right economic incentives for ISPs to deploy IPv6. And nobody in place to implement the needed policy, had the balls to do it. That IPv4 addresses ran out without IPv6 having reached a significant deployment should not have come as a surprise to anybody. That ISPs still believe IPv4 only is the best strategy even now, is however a bit surprising, and quite scary.
NAT was part of the reason it took such a long time to reach the point we are at now. And what good has it done us? It delayed the inevitable. But that extra time was not used to make us more prepared for it, as such we didn't get any benefit from NAT, which we can use to ease the deployment of IPv6. Also the delay has meant the network is now larger, which means more work and more expensive to upgrade, than it would have been, had it happened earlier. NAT also made the network more complicated, and many of the blockers in deploying IPv6 are due to problems caused by NAT. Moreover many people have gotten so used to NAT, they don't know how the Internet was supposed to work. And now they don't want IPv6 because it doesn't look like what they are used to. Lots of effort has been put into developing workarounds for the problems introduced by NAT. And none of them work great. All of that wasted effort would have been much better spent on getting IPv6 deployed in the first place.
You won't see many IPv6 only users on slashdot either. I'm wondering if I should change my signature to read "slashdot is part of the problem" until they eventually set up AAAA records for slashdot.
64:ff9b::/96 is allocated for exactly that purpose. And BIND has support for synthesising the AAAA records. But I don't see much benefit from such a deployment compared to dual stack plus CGN.
Exactly, that is a real challenge. And for that reason I think CGN + dual stack is more viable in some situations. Deploying CGN without dual stack is just screwing over the customers.
There are plenty of those sites around. But what you see even more are sites, which are available on IPv6, but are quite unreliable on IPv6. A couple of high profile examples include YouTube and facebook, which are much more reliable if you are on an IPv4 only connection, than if you have dual stack.
One of the blocking factors that kept websites from deploying IPv6 in the first place was a problem on the client side with clients which thought they had IPv6 support, but in reality did not. This is similar to the problem you describe, but is different. An ISP should of course not deploy IPv6 to their customers if they aren't going to have real connectivity to the IPv6 backbone. But as RFC 6598 addresses start seeing more use, there will be routes thinking they can use 2002:6440::/26 6to4 address space. Those clients will then think they have IPv6 connectivity, but won't be able to reach dual stack sites.
An ISP can actually avoid that particular problem by deploying native IPv6 to their customers. Once there is native IPv6, the routers won't bring up 6to4. That way you can avoid 6to4, which has been broken by RFC 6598.
That's interesting. I didn't know about that block. I'll keep that in mind as I might get involved with deployments, where this is applicable. I looked up the relevant RFC, which is RFC 6598. I find it interesting that this was taken out of ARIN address space. With ARIN being next in line to run out, this block must have accelerated depletion for ARIN.
/10 allocated for the purpose doesn't necessarily mean there will be millions of users behind a single CGN. A medium sized ISP could use this /10 to assign one address to each customer without having duplicated addresses within their own network, even if they plan to deploy multiple CGN devices to service their customers. That way customers of that ISP can communicate with each other as well as the ISPs own servers without going through CGN. It can also make management easier.
That there is a
I am curious what this means for usage of 2002:6440::/26 address space. Things could get interested. This is briefly covered in section 5.2.6 of the RFC.
More likely they'll just insert ads directly into the video stream. Sending ads as a separate video stream makes them quite easy to remove. But no doubt Google would be able to produce a new stream containing both ad and content. That won't stop downloading the video, but the downloaded version would include the ad.
Any artificial limitation, which puts somebody else's economic interests ahead of the interests of the owner of the device, should not have been legal in the first place.
A digital camera, which cannot store more than 30 pictures on a 128MB storage card when using the best quality setting is a limitation which exists for a good technical reason. Such a limitation is not artificial, and thus shouldn't be outlawed. But a digital camera that can only take panorama photos as long as they are stored on a storage card bought from the same vendor and not if the storage card was bought from a different vendor is an artificial limitation, which does not benefit the owner of the camera in any way. It must surely have been a little bit of extra work to implement the limitation in the first place, which is what characterizes artificial limitations.
Limitations which are there for safety reasons or to improve durability of the device are fine. For example storage media have extra capacity to compensate for imperfections in the media. That the logical capacity is less than the physical capacity is in the owner's interest, because otherwise the lifetime of the device would be significantly reduced. (It is also in the vendor's interest in order to reduce RMA cases. In some countries vendor's are subject to a minimum two year warranty.)
You could use a difficult to guess, but plausibly looking username like for example trillyps658. Then combine that with an easy to guess password like for example password12345. The username would be stored in plaintext in the database, the password would be salted and hashed like the rest of the database, but could be one of the first thousand passwords being attempted.
In that case, what you are detecting is really that the usernames are leaked and not the passwords. But if the passwords are too difficult to break, you may never learn, that the database has been leaked. You could also let the database contain email addresses and look for any email sent to some of those addresses.
How is that different from any other kind of gun?
You can only achieve that with a Caesar cipher, if the alphabet size is even. They split the English alphabet into two groups of 21 and 5 letters, which are not even numbers. If they had rotated the 20 consonants by 10 positions and the 6 vowels by 3 positions, it would have worked.
The only way to get hardware which "just works" with Linux is if the driver is in the mainline kernel. And to be in the mainline kernel it has to be open source. There is no such thing as a closed source driver which "just works", because part of the requirement for earning that label is that it also works after kernel interfaces have been changed in a way, which require a recompile of the driver.
If a piece of hardware "just works", I can download the source from kernel.org, compile it and then have that hardware work. Failing that, it does not "just work".
I hope this will be true. I dislike all the workarounds applied to stretch the supply of IPv4 addresses, and I dislike name based vhosts. I'd like to see HTTP 2.0 make both of those go away, and replace it with proper IPv6 setups.
There are technical reasons why you might want to share an IPv6 address between multiple websites. But those technical reasons can be addressed.
/64 to every VPS be wasting too many IPv6 addresses? Not really, there is no way we are going to run out of /64s to assign from, as long as we are constrained to one solar system. If you really wanted to, you could make the link prefix /124 and only use a /64 for the routed prefix.
/116 as local addresses for the server, and then allow the webserver to tell the kernel it want to bind a socket to say a /117 prefix rather than individual IPv6 addresses. I have no doubt those are features we will see in the future, if they haven't already been implemented by some kernels.
If we assume a webserver is hosting 1200 domains, what would happen if it was assigned a different IPv6 address for each of those domains? The answer depend on which technical solution you choose in order to do that.
The typical approach is that all of those IPv6 addresses are assigned out of the prefix on the link between the webserver and the router. Being on link, that means the router needs to perform neighbor discovery separately for each of those IPv6 addresses. The extra neighbor discovery traffic caused by this is not really a big deal, neither is the 0.1ms of extra latency when establishing a connection. But the router needs to store those entries in the neighbor table. If that table is implemented using CAM hardware for faster forwarding, it may have limited capacity.
So consuming CAM resources on the router is one possible technical reason why you might want to avoid having so many addresses.
There is a simple solution to that problem. Just use a routed prefix instead of the link prefix. If you route a prefix to the webserver, then the router just needs one routing table entry for that server instead of 1200 neighbor entries. Though a routing table entry may be more costly than one neighbor table entry, it is still cheaper than 100s of neighbor table entries.
I know of VPS providers, which don't want to assign routed prefixes to their customers. They might not yet have realized, that assigning routed prefixes can help saving resources for the provider.
Would assigning a separate routed
With the routed prefix in place for the webserver, the only place there could still be reasons for wanting to share an IPv6 address among multiple domains, would be in the software running on the server itself.
First of all, you'd typically need to tell the IPv6 stack in your kernel about each and every IPv6 address you want to use as a local IPv6 address of the server itself. If you wanted to use separate IPv6 addresses for each domain, you'd much rather be able to tell the kernel that you want it to treat an entire prefix like a
The lack of those features don't prevent you from actually assigning multiple addresses to your webserver. But the algorithms used by the kernel might not be tuned for this sort of usage. I wouldn't be surprised to hear about kernels, where CPU consumption is linear in the number of IPv6 addresses you have assigned. That could mean that the time it takes for the kernel to find out if a packet is meant for this machine goes up by a factor of 1200, potentially slowing your system to a crawl. And just configuring those addresses in the first place could take a while, as by each address you assign the CPU time needed to verify if it is new, goes up.
But a proper configuration with a routed prefix is possible today and will allow this to be done without wasting router resources, and after that it is just a minor tweak of the kernel on the server to support it efficiently. With those two in place, there are benefits to be had from assigning separate IPv6 addresses to each domain.
That statement makes no sense to me. The only sort of attack mentioned in the story is the DoS attack performed by another network blocking legitimate packets. There is no additional blocking that the server administrator could perform to solve that. And even if the server was under some other kind of attack (such as flooding), the only hostnames potentially involved are those assigned to the server itself. Blocking those hostnames, just means you are DoSing your own server. The attacker doesn't have a hostname, you can block them on.
You are assuming cryptography is all about protecting the confidentiality of data. That is a common mistake to make. But in this particular case I did point out in my initial post, that authenticity is also important. In fact in most cases authenticity and integrity of the data is more important than confidentiality.
Instead of asking what you can learn from observing mouse movements, consider what you can do if you control mouse movements. Most UIs have buttons located in predictable positions. Click on some of those to take control over the computer. All you need to be able to do is to navigate a browser to a malicious website and click yes on a few confirmations that you want to download some executable and run it. Sounds like a quite feasible task to achieve using a mouse.
Next ask if the receiving end of the wireless connection actually cares if it is a mouse or a keyboard. If it accepts keyboard input as well, then the attack is much easier to carry out, even if I didn't use any wireless keyboard myself.
As for the confidentiality, mouse movements used to be the primary source of randomness for use in cryptographic protocols. That certainly adds to the risk from somebody being able to observe all mouse movements.
I agree, those properties make scalability much easier. There is another possibility, which is if your data is mostly static. If you can simply copy your data to a bunch of servers and be done with it, then scalability is easy.
The real killer is if you have strong consistency requirements, and you have users worldwide, and data cannot be partitioned since users around the world need to read and modify the same data. If all of those are present you will be constrained by the speed of light, and putting all the smartest engineers in the world on one project won't increase the speed of light. You'll end up either relaxing the consistency requirements, artificially partitioning data, or increasing end user latency.
This sounds very much like premature optimization. You may end up designing a very scalable application and have the project fail due to too few users. If the actual number of users turn out to be an order of magnitude less than what you can handle on a single host, then all that scalability work was wasted. I think you have better chance of success with a quick proof of concept, which isn't very scalable.
It is ok to think about scalability before you have the users. But don't waste time implementing the scalable solution for a non-existing user-base.
The probability for a DNA molecule to appear without having used a pre-existing DNA molecule as template is tiny. Maybe it has only happened once in the entire lifetime of the Earth. In that case the orientation is completely random. It would be 50/50 for one orientation or the other. In that case if we ever find DNA based life elsewhere, the orientation of DNA molecules can give hints as to whether life has evolved independently or spread from a common origin.
It may be the probability is higher, and DNA created from scratch has happened more than once in the lifetime of the Earth. But if hundreds of years passed between the first two times it happens, it could be that life had already spread across the entire planet in the meantime. In that case the second DNA molecule could have caused some havoc in the area where it appeared, but eventually life around it adopted enough to wipe out the DNA molecule, that did not fit in.
Maybe both variants existed for some time, but during the evolution of life, one variant got extinct.
On my desktop computer I got a keyboard with a USB hub. A cable between keyboard and mouse is slightly less annoying than a cable from the mouse to the computer. On my laptop I am just using a trackpad. With training I have gotten more used to trackpads, and when I am travelling with my laptop, I often use it without access to a flat surface where I can put the mouse.
I'd still like a wireless mouse with strong cryptography and key exchange while it is charging. I think it would be feasible to use a one-time pad along with a provably secure message authentication code.
I for one never liked name based vhosts. I have started moving my own domains to IP based vhosts on IPv6. I still have one IPv4 address with name based vhosts for those users who don't have IPv6 yet. Configuring a vhost such that it was name based when accessed over IPv4 and IP based when accessed over IPv6 was slightly tricky. But I got it working.
I do like the idea of using this as an argument for deploying IPv6. Even though there are plenty of arguments for IPv6 already that doesn't stop some people from denying there is any need at all. So to me every argument I can find for deploying IPv6 is seen as a good thing. The more arguments we have, the harder it gets to deny the need for IPv6.
So the way it would have worked would be as follows. Hosting provider has one IPv4 address shared between many vhosts, but each vhost has their own IPv6 address. If one vhost is to be blocked for hosting illegal content, one IPv4 address and one IPv6 address can be blocked. If a user tries IPv4 first and gets a connection reset, their browser would switch to IPv6.
Then we can turn the story around and say MFU should have hosted on dual stack, then they wouldn't have been blocked. The opponents of IPv6 deployment will have many arguments to pull up, but I have an answer ready for each of them. They say: "But the users don't have IPv6, so they won't be able to reach the site anyway", and I say: "If those users had choosen an ISP with IPv6 support, they would have been able to reach the site". They say: "But there isn't any ISP with IPv6 support in that area", and I say: "If the ISP hasn't deployed IPv6, then they cannot justify IP based blocking, and they must instead route traffic to that IP through a router capable of doing DPI to only block the forbidden host-name".
Of course none of this is truly great arguments, because it is sort of accepting censorship. Even if you can target only a single domain, it is still censorship. And in case a domain contains both legal and illegal pages, and the domain uses https, then blocking without collateral damage is not technically possible.
No.
No.
If you can implement blocking which only blocks content found to be illegal by a court of law, then that is fine. But accepting any collateral damage and accepting any blocking without the content being found illegal by a court of law is just wrong. What I am saying is, stop doing filtering, and go for the root of the problem.
What makes you think I am special? There are billions of people who don't know either. If all of them just assume it must have been bad enough to justify this amount of collateral damage, then that is a free pass for those who want to apply censorship.
I don't believe that there could exist content so bad, that simply seeing it could be worse than living in a society of censorship.
I guess a major part of the problem might be, that there is no penalty for blocking too much. If there is a penalty for blocking too little but none for blocking too much, then there is little incentive to do accurate filtering. A discussion about whether blocking would have been appropriate in this case, had it been more accurately targeted, seems pointless, since we don't even know what content triggered the blocking. And that may actually be the largest problem with this sort of blocking.
Some do see it as a benefit though. How often have some country blocked the worlds largest sites on the excuse that one page on each site is offending their religion. The more coarse grained your filtering is, the easier it is to conceal what you were really aiming to censor and the easier it is to find a plausible excuse for applying the filter in the first place. A civilized country shouldn't accept censorship, and especially not when it comes with such collateral damage. I don't believe there exist a problem in this world, for which censorship is the best solution.
I could say, because in the past I have been working on the team responsible for making backup copies of Gmail on tape. But I think the underlying storage system has been replaced since I worked on it. But a few of the key points haven't changed.
Once a user delete a message it does become inaccessible to that user. But it doesn't mean that all copies will be gone instantly. Having all copies be gone instantly would completely defy the purpose of having backup copies in the first place. The point of backups is that you can get back stuff, which you have accidentally deleted.
You could design a system where you could guarantee that the last copy was deleted exactly x days after the user hit the delete button. But designing for such an exact guarantee would require more resources. Instead you could have a system where the guarantee was that the last copy would be deleted between x and 3x days after the user hit the delete button. This flexibility allows for a simpler and cheaper design. I don't know what sort of range Gmail operates with these days, neither if the number is published.
For a data transfer such as the one we are talking about here none of those deleted mails should be part of the transfer. If they were, that would sound like a mistake on Google's part, but I don't think that is what happened. I think your explanation sounds more likely.
If Sky had said they wanted any email deleted in the last x days to be restored from backup to be part of the transfer, then that would have sounded like a completely unreasonable request to a lot of people. I think Google would have argued, that it would not be in the users' interest to do so.
As long as the message is no longer visible to POP clients, they are indeed following the protocol. The POP protocol does not require the server to find every copy of the message in existence across all servers on the Internet and delete them. If downloading the mail to your computer caused the copy accessible through the webinterface to get deleted, people would be screaming about data loss. Gmail offers four possible configurations on what happens to the copy in the webinterface when the copy accessible through POP is deleted. It looks like the default is to do nothing, which treats them as independent copies.
I'm sure Sky could have gotten a different default setting for their own customers, if they had asked for it. But why would they have asked for a default setting, which would cause data loss for those users, who did not fully understand the system, they were working with.
POP is an outdated protocol, which was not designed for a world where users want to access their email on multiple devices. Rather than telling users they had to upgrade to IMAP or implementing POP in a way that was useless to most of the users, Google decided to implement something that was working well for the users.