Most enterprise "LAN" switches are protocol aware, however. Ever heard of a VLAN?
VLAN is on a protocol layer just under conventional Ethernet. As such it doesn't know anything about protocols on top of it.
QoS?
It is possible for a switch to inspect the payload looking for headers at a much higher protocol layer than a switch should be concerning itself with, and apply different routing policy depending on what it finds.
In the worst case such a switch would put IPv6 packets into random queues misinterpreting the headers. If you are pushing your network hard enough to need QoS at this level, then this could cause undesired behaviour. If the network is not congested, the IPv6 packets will still make it through to the proper destination.
I think in most cases the need for QoS is on routers and not on switches. But the way the chips work nowadays, there is no longer such a clear distinction between a switch and a router. Technically if it uses MAC address to choose outgoing interface it is a switch, and if it use IP address to choose outgoing interface, it is a router. But some hardware can do either of those depending on configuration.
Anyway, a company that actually need QoS on their local network should have network engineers with sufficient knowledge that they are also aware of the need for IPv6 and have a plan for how to get there.
Technically, if your hash algorithm is too fast, it gets easier to brute force.
Let's assume somebody came up with a hash function that is 10 times faster than what we would otherwise use, and let's assume it is just as secure except from the minor detail that by being 10 times faster it also becomes 10 times faster to perform a brute force attack. If those assumptions are true, then instead of discarding it altogether, we should find a way to make the brute force attacks slower again. Making the algorithm slower would of course achieve that, but that's not a good idea because it would become less useful. Instead we can use the same principles for the hash function, but increase the size of the output with one byte. That extra byte makes the time to find a collision 16 times larger (and preimage attacks takes 256 times longer). But why stop at one byte, we could make the hash value a lot larger. Even if that meant it would slow down by a factor of two, it would still be five times faster than the alternatives and a lot more secure.
This is exactly the reason why modern hash functions no longer output just 128 bits. These days nobody in his right mind would try to design a new cryptographic hash that output less than 256 bits.
IPv6 has made this a lot harder because the UDP or TCP port number is no longer at a fixed offset from the start of the packet. Instead the router has to parse variable-length extra headers.
If anybody decides to put functionality in a router that looks at those fields, then they are doing it wrong. It is not the protocol's fault if somebody decides to implement it in a way it wasn't intended to.
The port numbers never were on a fixed offset, not even with IPv4. There could be options in the header, in which case the transport header would start at a different offset. Secondly the port numbers don't even exist in all protocols. There could be tunnelling, in which case there would be another header before the transport header. It is even possible that the transport header was encrypted in that case.
There is a field in the IPv6 header that serves to handle those cases where a router might want to distinguish between different traffic flows between the same set of hosts. It is called the flow label, and that is what a router is supposed to be using in those cases.
Except that routers really only care about 1 field, the destination address.
That is not entirely correct. They have to care about the TTL/Hop limit field as well. If they didn't, then a routing loop would take out the network. Every router has to update this field, and in IPv4 that meant they had to update the header checksum as well. They also have to care about the length of the packet, though you may get away with only caring about the length at the link level. The rest of the header fields can be ignored.
They SHOULD care about other fields so that thins like DONT_FRAGMENT gets honored
I am not aware of any cases where that is ignored. I never saw a case where a packet with the bit set got fragmented. It is a common mistake to drop the packet without sending the proper ICMP message back to the sender. There is several ways this could go wrong, I don't know which of them is predominant. (Never send the ICMP packet, drop the ICMP packet somewhere on the path back, generate an ICMP response that is too large to make it back).
This is the one thing that was simplified the most in IPv6. In IPv4 every router had to look at this bit and use it to find out which of two ways to behave it had to follow. In IPv6 the don't fragment bit does not exist anymore, it is implied to be true. An IPv6 router must always respond with an ICMP packet. Fragmenting the packet is no longer possible. The header fields used for fragmentation were removed. (If desired, the sender can fragment the packet before it enters the network and include an option header with the necessary fields. No router has to look at this option header, only the final recipient needs to look at it).
So you've effectively made the only field they care about much larger, even taking into account half of it can be/is just the mac address which actually makes things easier.
First of all, the addresses were increased in size because they were too small to begin with. However, a router only needs to look at the first half of the destination address except in those cases where the final destination is on a directly attached network.
Ok, so the router now have to consider 64 bits of the address for routing, where it used to be considering only 24 or 32 bits. However the table it has to process is likely going to be much smaller since with IPv6 it will more often be the case that an ISP has a contiguous range of IP addresses, so even that part of the processing may be cheaper with IPv6.
You can use the MAC address to choose an IPv6 address if you want something that doesn't require configuration of individual machines. But there are plenty of other ways an IPv6 address can be configured.
Actually ipv6 is less environmentally friendly as it requires bits to be thrown back and forth to get the job done
Just in case somebody could be mislead to think you were serious, let me point out that the total number of fields in the header was reduced by 38% when switching from IPv4 to IPv6. That should allow for less processing power being used by the routers. The size of addresses was quadrupled, but the accumulated size of the other mandatory header fields was reduced by a third, in total that means the header only doubled in size.
Furthermore packets are something like 1.5k in size max with only something like 0.5k for actual application data
With IPv4 the maximum is around 64KB. However it is not required for everybody to support that large packets. If you send a packet that is too large for the destination or a router on the way it will either be split or an error message is sent back to the sender (which of the two is decided by the sender setting a bit in the header). On of the most frequent mistakes in configuring the network is to throw away packets that are too large without telling the sender.
There need to be some minimum where you are guaranteed that a packet under that size will reach the destination. For IPv4 that size is defined as 68 bytes for individual packets and 576 bytes for the full reassembled packet. Notice that 68 is ridiculously small by today's standards. I think most modern operating systems supports the full 64KB. The maximum size of the individual parts (known as the MTU) is typically 1500 bytes as that is the size supported by Ethernet.
In most cases you want to avoid fragmentation of IP packets because if one part is lost by the network, then the remaining parts cannot be used for anything. Data larger than 1500 bytes is usually send using TCP, which does support retransmitting just the fragments that were lost.
It is possible to let TCP segment the data stream and then let IP fragment each segment, but the only gain is that you don't have to to send TCP headers as frequently. If you have a 68 byte MTU, then the TCP header is a significant part of the MTU, and such fragmentation makes sense. In more typical cases with an MTU of 1KB or more, the 20 bytes for the TCP header are well spent, and you usually try to send packets exactly the size where they don't have to be fragmented further.
A typical packet nowadays is a TCP packet with 20 bytes IPv4 header, 20 bytes TCP header, 12 bytes TCP options and up to 1448 bytes payload.
With IPv6 the limits have been increased. The minimum MTU was increased from 68 bytes to 1280 bytes. The minimum reassembled packet was increased from 576 to 1500 bytes, and the IP header was increased from 20 to 40 bytes. (Even though the size of the addresses was quadrupled, the header size was only doubled because everything else in the header was simplified). With IPv6 the 1280 bytes is large enough that often it is a good idea to just stay within the 1280 bytes to avoid problems with routers that don't support larger packets. It is close enough to 1500 bytes to get good efficiency in most situations, and there is sufficient gap between 1280 and 1500 to allow for a few extra headers in case of tunnelling. That would mean a typical TCP packet has 40 bytes of IPv6 header, 20 bytes of TCP header, 12 bytes of TCP options, and up to 1208 bytes of payload.
The bit in the header, which indicates if the packet should be split or bounced in case it is too large was eliminated with IPv6. In IPv6 the packets are always bounced if they are too large. That also means the header fields for reassembly were removed. The sender can decide to split the packet and include an IPv6 option header, but it still won't be split further by routers on the network.
You can have an option header specifying which route you want the packet to take rather than just a destination. But many networks will just drop the packet if you try to.
Who would actually trust those people to give access to the data after receiving payment? What is the most profitable thing to do after somebody have paid? Give them their data back or demand more money. Granted, very few people would be stupid enough to pay twice. But even if one person would fall for that, it would mean more money to them. And people are more likely to pay more money if they can make it look like the sucker was just unlucky and they didn't intentionally fail to give the data back. For example make the browser crash at the point where it "should" have shown the password.
If everyone lives forever barring violent death, a two-baby rule would lead to overpopulation.
Only if you assume that everybody makes full use of the quota. If you assume the two children is a maximum and a very small percentage of people get less, then the total number of people ever born will be limited. And if you also assume that it is possible to die given sufficiently unfortunate circumstances, then the total number of people alive will converge towards zero (with a potentially long half time).
So, a two child limit would (if it could be enforced) solve overpopulation on the long term. A one child limit will cause population to decrease "fast" with a half time of one generation. You could come up with some middle ground between the two. For example you could say you are allowed to have two children if at least one of the parents is a single child. If both parents have siblings, only one child is allowed.
But of course enforcing it is problematic no matter how you define the limit. Counting it is easier if you apply the limit to the mother. But, what would you do with a pregnant woman who is not allowed to give birth to another child?
Sound cards used to be sold because their ability to decode sound was done on the card rather than having the CPU doing it
True, the CPU cannot decode sound, because it does not have a D/A converter. And getting a D/A converter was the reason you would put a sound card in a PC. Such stuff as decoding MP3 for sure wasn't part of the first sound cards. The most advanced sound cards may have had some midi stuff on the card as well.
The quality of the D/A converter and everything in the chain after it can influence the quality of the sound. And I can believe onboard sound chips don't have the best quality.
Most likely that depends on the error rate of the physical hardware. The more errors the fault tolerance has to deal with, the more overhead there will be.
does it affect real time latency?
Latency is not really what is important to quantum computers. The typical use case for quantum computers is long running computations. The more interesting question is by how large a factor does the number of qubits increase, and does the possible number of qubits in a quantum computer increase fast enough with little increase in error rate to make such techniques useful? The next question will be by which factor the computation will be slowed down. But if the technique is feasible then the slowdown probably doesn't matter as the quantum computer will be much faster than all the alternatives anyway.
I recall hearing a talk about how to do fault tolerant quantum computing already six years ago. The main points I remember from the talk was that there was a theoretical limit to how much redundancy you could introduce as if you could reconstruct from half the qubits then you could clone the state, which is known to be impossible. I don't remember how large the gap was between the upper and lower bounds were, but they proved that at a certain error rate their redundant construction would improve the error rate, and could be applied multiple times to get even better error rates.
I'm, uh, taking a wild guess that simply shutting off port 80 is not going to allow for a controllable ramp up...
Both approaches allow for a controllable ramp up given the right software on their servers. And I think with the typical off the shelf software neither of them allow for a controllable ramp up.
But did they even need a controllable ramp up of user requests? It sounded like the overloaded system was overloaded by internal requests, that were unrelated to the number of requests they got from end users.
My guess is they simply did what they found the easiest way to get their internal systems working again and not worrying about what errors users would see in the meantime.
Some people think technology should be replaced just because it is old. But really, it should be replaced if it doesn't suit our needs and there is a different technology that does suit it.
It is better to replace a 1 year old technology that does not suit our needs than to replace a 50 year old one that does. Usually when replacing, you want to replace with something newer. But in some cases it may turn out to be better to replace a new and misdesigned technology with an older and proven one.
That said, there are improvements to both IP and DNS which should be rolled out because they fix real problems. The rollouts are not happening as fast as they ought to, mainly because it is problematic to roll out a change to the entire Internet, especially when not everybody involved is cooperating.
But I don't think that really has anything to do with this outage.
I think that comment was referring to the fact that some recent announcement said there are now 5 billion devices on the internet, and IPv4 supports only up to 3.7 billion devices.
Notice the page, being served from facebook.com, saying "bad DNS".
I can understand why that may cause people to think the problem is with DNS. The error message looks like it came from an http proxy. That would suggest that either the user had a proxy configured or facebook were using a reverse proxy. If it was the later, the DNS "problem" would be inside their network.
There isn't a compelling reason for businesses to roll out IPv6 because most of the world is still on IPv4. Nobody will be visiting you v6 website.
However popular this explanation is, it may actually be slightly distorted. It's not that hard to deploy IPv6 that it would stop all websites from doing so. A lot of websites would deploy IPv6 even if it only meant that a very small number of additional users could access it. Maybe those users count for something, and getting started now means you will be prepared when in a few years time there will be an increasing number of clients that can only access your website over IPv6. However, there is a slightly different reason for websites to be hesitating with IPv6 support.
The problem is that even though you may expect a website with both IPv4 and IPv6 support to be accessible to more users that one with only IPv4 support, it isn't actually so. By supporting only IPv4 your website is accessible to more users than if you support both. The reason for this is that once you enable IPv6 for your domain, many clients will start using that by default, even some clients that do not have IPv6 connectivity. If your computer thinks it has both IPv4 and IPv6 connectivity, there is a chance it will use IPv6 by default for any website supporting it. If it turns out you only have IPv4 connectivity, and the IPv6 connection your computer thought it had, isn't working, then you can access IPv4 only websites but not websites supporting both IPv4 and IPv6.
As long as the number of users with this kind of broken connectivity is larger than the number of users who have only IPv6 and no IPv4, there is very little incentive for websites to deploy IPv6. Would you want to make your site inaccessible to a small percentage of your current users in order to make it accessible for a much smaller group of users?
Currently this looks like the biggest hurdle for deploying IPv6. A large part of this problem could be solved by making webbrowsers better at dealing with flaky connectivity. One option is to open two TCP connections simultaneously (one over IPv4 and one over IPv6) and use the first one to complete a TCP handshake. Unfortunately it will cause some extra load on the webservers, but at the current time that extra load would be minor since it would only happen for those users that actually do have working IPv6 connectivity.
A different approach could be to first open one connection, and if the handshake has not completed in 200ms open the next, then use the first one to complete the handshake. And for each website remember which of the two you used the last time and make that the first you attempt for the next connection.
A little bit more intelligence would be required for cases with misconfigured routers causing PMTU discovery to break. In those cases the handshake would work, but the connection would stall the first time one party tries to send a large packet. For this to work you would have to detect this kind of scenario and switch protocol after some data has been sent. That would mean resending requests, which isn't allowed for all kinds of requests as POST requests are not guaranteed to be idempotent. Browsers could also just set a low mss for all connections they open over IPv6.
Has anyone ever heard of a government wanting to dish out compensation?
Not exactly, but it's close. In Denmark there are politicians talking positively about such ideas. It is of course way too early to say if it will happen, but it isn't totally unlikely.
I think slashdot should take at least one step in that direction. Currently slashdot is not available over IPv6. Why doesn't a site like slashdot get IPv6 connectivity to the servers and set up an AAAA record?
Consider the following though experiment. Imagine a few years from now the hysteria reaches a level where society decides to destroy all of those vases and pictures of them. Then imagine what history "books" a thousand years from now will say about our time. Will it focus more on the child porn problem or the destruction of cultural heritage?
SSL Script Exploit with more information available here!
This is why for anything important you have to use https from the very beginning. I always use https URLs from my browser history or a bookmark if it is something critical. (For web access to my bank I go as far as looking at the certificate chain every time I login).
There are a few annoyances that makes it a bit harder to follow such practices. First of all some browsers will strip off the https:/// part when finding a URL in the history. And if I type in the URL by hand I have to type the entire https:/// part because all browsers I know default to http://./ Browsers can't just switch to https as the default because many sites don't support https. If the browser tried https first and then http if it got a RST on https it wouldn't help because an attacker can just send that RST.
In short the attacks described in the first part of that article either only work against old buggy browsers, and those in the last part only work against people who don't have sufficient understanding of how https works.
I know it's not the N1, but I can say that the Droid has a SIP application which works..pretty well.
Which SIP application is it? I have been experimenting with Sipdroid myself, but I couldn't get it to work. Could be a problem with my SIP provider, but Ekiga works a lot better even when I am using Sipdroid and Ekiga from the same network.
Actually, read permissions are meaningless for directories so far I know, so 0755 is equivalent to 0311 for directories.
No, read permission certainly does have a meaning for directories. Write permissions for a directory does pretty much what you would expect (some semantics are a bit more tricky if the sticky bit is set on the directory). Read permission means you can get a list of the names in the directory, execute permissions means you can do most things with those entries (except from those operations that require write permission). So, if you have read but no execute you can get a list of names in the directory, but you cannot do anything with them, you can't even tell if they are files or directories. If you have execute but no read, you can access everything as long as you know the name of it (or can guess the name).
[/tmp] mkdir test [/tmp] touch test/file [/tmp] ls -l test total 0 -rw-rw-r-- 1 kasperd kasperd 0 2009-12-27 00:44 file [/tmp] chmod 400 test [/tmp] ls -l test ls: cannot access test/file: Permission denied total 0 -[Interesting part removed because of a bug in slashdot] file [/tmp] chmod 100 test [/tmp] ls -l test ls: cannot open directory test: Permission denied [/tmp] ls -l test/file -rw-rw-r-- 1 kasperd kasperd 0 2009-12-27 00:44 test/file [/tmp]
Any crypto experts want to take a stab at explaining
The article doesn't contain enough information about A5/1 or the details of the attack for a crypto expert to explain exactly what he plan to do. However it does mention that he intend to create a rainbow table, so I can at least explain what a rainbow table is, and what the 128PB might mean. The article say it is a 64 bit encryption, but 128PB doesn't sound like the right size given a 64 bit encryption, the 128PB sounds more like a 54 bit encryption. And though it doesn't sound like a huge difference those 10 bits does mean a factor of 1024 times less work to brute force, and these days the difference between 54 and 64 bits may very well be the difference between feasible and not feasible to break. Of course in a few years 64 bits may be feasible to brute force as well.
Compressing 128PB down to 2-3TB doesn't sound realistic at first, but then consider that those 128PB are not just 128PB of random data, they are generated by a very simple algorithm. The entire code to generate those 128PB would probably fit in less than 1MB. But the time it would take to actually run the code for long enough to generate the 128PB is prohibitive. Also notice, that what is going to happen is not really a compression of the 128PB of data. The output of the algorithm is going to be a few TB of data, but that data can't actually be used to reproduce the original 128PB of data, which wouldn't be very interesting anyway. What you really want is a function that given some input can output the encryption key, and that can happen through a very simple table lookup, which would be very fast, but infeasible since very few people have the resources to store the complete 128PB lookup table. Instead you use a more complicated algorithm, which use 50.000 times less stored data, but OTOH may run 100.000 times (or even more) slower than the simple table lookup. But 100.000 table lookups would still only take a fraction of a second on a modern CPU.
Back to the rainbow tables. It is a tool to speed up the task of reversing a one way function. A one way function is a function that maps from one set of values to another set of values. The function is fast to compute in one direction, but there is no simple way to compute in the other direction. One example of a one way function is a hash function, which maps from strings of arbitrary lengths to the much smaller set of strings of one fixed length.
Let's assume our one way function is called f and maps from the set S to the set T. Then we can define a different function g, which maps from T to some interesting subset of S. For example it has been used in the past with a function that maps from 128 bit strings (outputs from MD5) to the set of passwords consisting of 7 alphanumeric characters (which is a subset of the possible inputs to MD5). If you combine g and f, you get a function mapping from T to T. If you start with a value in T and keep applying this combination, you will keep getting values in T.
Now you decide how many times in a row you will apply this combination, let's call that number n. A small n will produce very large rainbow tables, that may be faster to use. OTOH a large n will produce smaller rainbow tables that will be slower to use. This choice is the compromise mentioned in the article. He is probably going to use a value of n around 65536 or so.
Now you start producing chains (this is the large amount of work that this project will aim to distribute). You take some input in T, then you apply the combination of the two functions n times and get an output in T. You repeat that with a few hundred billion different values in T. The output will be a lot of pairs of values, from those pairs you create a lookup table.
Now assume you have a value x, which is the output of the one way function f, and you want to find out what the input may have been. Then you can apply the combination of functions n times and get n different values in T, look
You think that is bad? Some years back a seven year old girl got Mousehunt or so it said on the box that had been bought from a toy store. However the contents of the box turned out to be a porn movie called big nuts.
Slashdot Mirror
VLAN is on a protocol layer just under conventional Ethernet. As such it doesn't know anything about protocols on top of it.
It is possible for a switch to inspect the payload looking for headers at a much higher protocol layer than a switch should be concerning itself with, and apply different routing policy depending on what it finds.
In the worst case such a switch would put IPv6 packets into random queues misinterpreting the headers. If you are pushing your network hard enough to need QoS at this level, then this could cause undesired behaviour. If the network is not congested, the IPv6 packets will still make it through to the proper destination.
I think in most cases the need for QoS is on routers and not on switches. But the way the chips work nowadays, there is no longer such a clear distinction between a switch and a router. Technically if it uses MAC address to choose outgoing interface it is a switch, and if it use IP address to choose outgoing interface, it is a router. But some hardware can do either of those depending on configuration.
Anyway, a company that actually need QoS on their local network should have network engineers with sufficient knowledge that they are also aware of the need for IPv6 and have a plan for how to get there.
Let's assume somebody came up with a hash function that is 10 times faster than what we would otherwise use, and let's assume it is just as secure except from the minor detail that by being 10 times faster it also becomes 10 times faster to perform a brute force attack. If those assumptions are true, then instead of discarding it altogether, we should find a way to make the brute force attacks slower again. Making the algorithm slower would of course achieve that, but that's not a good idea because it would become less useful. Instead we can use the same principles for the hash function, but increase the size of the output with one byte. That extra byte makes the time to find a collision 16 times larger (and preimage attacks takes 256 times longer). But why stop at one byte, we could make the hash value a lot larger. Even if that meant it would slow down by a factor of two, it would still be five times faster than the alternatives and a lot more secure.
This is exactly the reason why modern hash functions no longer output just 128 bits. These days nobody in his right mind would try to design a new cryptographic hash that output less than 256 bits.
If anybody decides to put functionality in a router that looks at those fields, then they are doing it wrong. It is not the protocol's fault if somebody decides to implement it in a way it wasn't intended to.
The port numbers never were on a fixed offset, not even with IPv4. There could be options in the header, in which case the transport header would start at a different offset. Secondly the port numbers don't even exist in all protocols. There could be tunnelling, in which case there would be another header before the transport header. It is even possible that the transport header was encrypted in that case.
There is a field in the IPv6 header that serves to handle those cases where a router might want to distinguish between different traffic flows between the same set of hosts. It is called the flow label, and that is what a router is supposed to be using in those cases.
That is not entirely correct. They have to care about the TTL/Hop limit field as well. If they didn't, then a routing loop would take out the network. Every router has to update this field, and in IPv4 that meant they had to update the header checksum as well. They also have to care about the length of the packet, though you may get away with only caring about the length at the link level. The rest of the header fields can be ignored.
I am not aware of any cases where that is ignored. I never saw a case where a packet with the bit set got fragmented. It is a common mistake to drop the packet without sending the proper ICMP message back to the sender. There is several ways this could go wrong, I don't know which of them is predominant. (Never send the ICMP packet, drop the ICMP packet somewhere on the path back, generate an ICMP response that is too large to make it back).
This is the one thing that was simplified the most in IPv6. In IPv4 every router had to look at this bit and use it to find out which of two ways to behave it had to follow. In IPv6 the don't fragment bit does not exist anymore, it is implied to be true. An IPv6 router must always respond with an ICMP packet. Fragmenting the packet is no longer possible. The header fields used for fragmentation were removed. (If desired, the sender can fragment the packet before it enters the network and include an option header with the necessary fields. No router has to look at this option header, only the final recipient needs to look at it).
First of all, the addresses were increased in size because they were too small to begin with. However, a router only needs to look at the first half of the destination address except in those cases where the final destination is on a directly attached network.
Ok, so the router now have to consider 64 bits of the address for routing, where it used to be considering only 24 or 32 bits. However the table it has to process is likely going to be much smaller since with IPv6 it will more often be the case that an ISP has a contiguous range of IP addresses, so even that part of the processing may be cheaper with IPv6.
You can use the MAC address to choose an IPv6 address if you want something that doesn't require configuration of individual machines. But there are plenty of other ways an IPv6 address can be configured.
Just in case somebody could be mislead to think you were serious, let me point out that the total number of fields in the header was reduced by 38% when switching from IPv4 to IPv6. That should allow for less processing power being used by the routers. The size of addresses was quadrupled, but the accumulated size of the other mandatory header fields was reduced by a third, in total that means the header only doubled in size.
With IPv4 the maximum is around 64KB. However it is not required for everybody to support that large packets. If you send a packet that is too large for the destination or a router on the way it will either be split or an error message is sent back to the sender (which of the two is decided by the sender setting a bit in the header). On of the most frequent mistakes in configuring the network is to throw away packets that are too large without telling the sender.
There need to be some minimum where you are guaranteed that a packet under that size will reach the destination. For IPv4 that size is defined as 68 bytes for individual packets and 576 bytes for the full reassembled packet. Notice that 68 is ridiculously small by today's standards. I think most modern operating systems supports the full 64KB. The maximum size of the individual parts (known as the MTU) is typically 1500 bytes as that is the size supported by Ethernet.
In most cases you want to avoid fragmentation of IP packets because if one part is lost by the network, then the remaining parts cannot be used for anything. Data larger than 1500 bytes is usually send using TCP, which does support retransmitting just the fragments that were lost.
It is possible to let TCP segment the data stream and then let IP fragment each segment, but the only gain is that you don't have to to send TCP headers as frequently. If you have a 68 byte MTU, then the TCP header is a significant part of the MTU, and such fragmentation makes sense. In more typical cases with an MTU of 1KB or more, the 20 bytes for the TCP header are well spent, and you usually try to send packets exactly the size where they don't have to be fragmented further.
A typical packet nowadays is a TCP packet with 20 bytes IPv4 header, 20 bytes TCP header, 12 bytes TCP options and up to 1448 bytes payload.
With IPv6 the limits have been increased. The minimum MTU was increased from 68 bytes to 1280 bytes. The minimum reassembled packet was increased from 576 to 1500 bytes, and the IP header was increased from 20 to 40 bytes. (Even though the size of the addresses was quadrupled, the header size was only doubled because everything else in the header was simplified). With IPv6 the 1280 bytes is large enough that often it is a good idea to just stay within the 1280 bytes to avoid problems with routers that don't support larger packets. It is close enough to 1500 bytes to get good efficiency in most situations, and there is sufficient gap between 1280 and 1500 to allow for a few extra headers in case of tunnelling. That would mean a typical TCP packet has 40 bytes of IPv6 header, 20 bytes of TCP header, 12 bytes of TCP options, and up to 1208 bytes of payload.
The bit in the header, which indicates if the packet should be split or bounced in case it is too large was eliminated with IPv6. In IPv6 the packets are always bounced if they are too large. That also means the header fields for reassembly were removed. The sender can decide to split the packet and include an IPv6 option header, but it still won't be split further by routers on the network.
You can have an option header specifying which route you want the packet to take rather than just a destination. But many networks will just drop the packet if you try to.
Who would actually trust those people to give access to the data after receiving payment? What is the most profitable thing to do after somebody have paid? Give them their data back or demand more money. Granted, very few people would be stupid enough to pay twice. But even if one person would fall for that, it would mean more money to them. And people are more likely to pay more money if they can make it look like the sucker was just unlucky and they didn't intentionally fail to give the data back. For example make the browser crash at the point where it "should" have shown the password.
Only if you assume that everybody makes full use of the quota. If you assume the two children is a maximum and a very small percentage of people get less, then the total number of people ever born will be limited. And if you also assume that it is possible to die given sufficiently unfortunate circumstances, then the total number of people alive will converge towards zero (with a potentially long half time).
So, a two child limit would (if it could be enforced) solve overpopulation on the long term. A one child limit will cause population to decrease "fast" with a half time of one generation. You could come up with some middle ground between the two. For example you could say you are allowed to have two children if at least one of the parents is a single child. If both parents have siblings, only one child is allowed.
But of course enforcing it is problematic no matter how you define the limit. Counting it is easier if you apply the limit to the mother. But, what would you do with a pregnant woman who is not allowed to give birth to another child?
True, the CPU cannot decode sound, because it does not have a D/A converter. And getting a D/A converter was the reason you would put a sound card in a PC. Such stuff as decoding MP3 for sure wasn't part of the first sound cards. The most advanced sound cards may have had some midi stuff on the card as well.
The quality of the D/A converter and everything in the chain after it can influence the quality of the sound. And I can believe onboard sound chips don't have the best quality.
Unfortunately when I follow the link it just ends up in a redirection loop.
Most likely that depends on the error rate of the physical hardware. The more errors the fault tolerance has to deal with, the more overhead there will be.
Latency is not really what is important to quantum computers. The typical use case for quantum computers is long running computations. The more interesting question is by how large a factor does the number of qubits increase, and does the possible number of qubits in a quantum computer increase fast enough with little increase in error rate to make such techniques useful? The next question will be by which factor the computation will be slowed down. But if the technique is feasible then the slowdown probably doesn't matter as the quantum computer will be much faster than all the alternatives anyway.
I recall hearing a talk about how to do fault tolerant quantum computing already six years ago. The main points I remember from the talk was that there was a theoretical limit to how much redundancy you could introduce as if you could reconstruct from half the qubits then you could clone the state, which is known to be impossible. I don't remember how large the gap was between the upper and lower bounds were, but they proved that at a certain error rate their redundant construction would improve the error rate, and could be applied multiple times to get even better error rates.
Both approaches allow for a controllable ramp up given the right software on their servers. And I think with the typical off the shelf software neither of them allow for a controllable ramp up.
But did they even need a controllable ramp up of user requests? It sounded like the overloaded system was overloaded by internal requests, that were unrelated to the number of requests they got from end users.
My guess is they simply did what they found the easiest way to get their internal systems working again and not worrying about what errors users would see in the meantime.
Some people think technology should be replaced just because it is old. But really, it should be replaced if it doesn't suit our needs and there is a different technology that does suit it.
It is better to replace a 1 year old technology that does not suit our needs than to replace a 50 year old one that does. Usually when replacing, you want to replace with something newer. But in some cases it may turn out to be better to replace a new and misdesigned technology with an older and proven one.
That said, there are improvements to both IP and DNS which should be rolled out because they fix real problems. The rollouts are not happening as fast as they ought to, mainly because it is problematic to roll out a change to the entire Internet, especially when not everybody involved is cooperating.
But I don't think that really has anything to do with this outage.
I think that comment was referring to the fact that some recent announcement said there are now 5 billion devices on the internet, and IPv4 supports only up to 3.7 billion devices.
I can understand why that may cause people to think the problem is with DNS. The error message looks like it came from an http proxy. That would suggest that either the user had a proxy configured or facebook were using a reverse proxy. If it was the later, the DNS "problem" would be inside their network.
However popular this explanation is, it may actually be slightly distorted. It's not that hard to deploy IPv6 that it would stop all websites from doing so. A lot of websites would deploy IPv6 even if it only meant that a very small number of additional users could access it. Maybe those users count for something, and getting started now means you will be prepared when in a few years time there will be an increasing number of clients that can only access your website over IPv6. However, there is a slightly different reason for websites to be hesitating with IPv6 support.
The problem is that even though you may expect a website with both IPv4 and IPv6 support to be accessible to more users that one with only IPv4 support, it isn't actually so. By supporting only IPv4 your website is accessible to more users than if you support both. The reason for this is that once you enable IPv6 for your domain, many clients will start using that by default, even some clients that do not have IPv6 connectivity. If your computer thinks it has both IPv4 and IPv6 connectivity, there is a chance it will use IPv6 by default for any website supporting it. If it turns out you only have IPv4 connectivity, and the IPv6 connection your computer thought it had, isn't working, then you can access IPv4 only websites but not websites supporting both IPv4 and IPv6.
As long as the number of users with this kind of broken connectivity is larger than the number of users who have only IPv6 and no IPv4, there is very little incentive for websites to deploy IPv6. Would you want to make your site inaccessible to a small percentage of your current users in order to make it accessible for a much smaller group of users?
Currently this looks like the biggest hurdle for deploying IPv6. A large part of this problem could be solved by making webbrowsers better at dealing with flaky connectivity. One option is to open two TCP connections simultaneously (one over IPv4 and one over IPv6) and use the first one to complete a TCP handshake. Unfortunately it will cause some extra load on the webservers, but at the current time that extra load would be minor since it would only happen for those users that actually do have working IPv6 connectivity.
A different approach could be to first open one connection, and if the handshake has not completed in 200ms open the next, then use the first one to complete the handshake. And for each website remember which of the two you used the last time and make that the first you attempt for the next connection.
A little bit more intelligence would be required for cases with misconfigured routers causing PMTU discovery to break. In those cases the handshake would work, but the connection would stall the first time one party tries to send a large packet. For this to work you would have to detect this kind of scenario and switch protocol after some data has been sent. That would mean resending requests, which isn't allowed for all kinds of requests as POST requests are not guaranteed to be idempotent. Browsers could also just set a low mss for all connections they open over IPv6.
Not exactly, but it's close. In Denmark there are politicians talking positively about such ideas. It is of course way too early to say if it will happen, but it isn't totally unlikely.
I think slashdot should take at least one step in that direction. Currently slashdot is not available over IPv6. Why doesn't a site like slashdot get IPv6 connectivity to the servers and set up an AAAA record?
Consider the following though experiment. Imagine a few years from now the hysteria reaches a level where society decides to destroy all of those vases and pictures of them. Then imagine what history "books" a thousand years from now will say about our time. Will it focus more on the child porn problem or the destruction of cultural heritage?
This is why for anything important you have to use https from the very beginning. I always use https URLs from my browser history or a bookmark if it is something critical. (For web access to my bank I go as far as looking at the certificate chain every time I login).
There are a few annoyances that makes it a bit harder to follow such practices. First of all some browsers will strip off the https:/// part when finding a URL in the history. And if I type in the URL by hand I have to type the entire https:/// part because all browsers I know default to http://./ Browsers can't just switch to https as the default because many sites don't support https. If the browser tried https first and then http if it got a RST on https it wouldn't help because an attacker can just send that RST.
In short the attacks described in the first part of that article either only work against old buggy browsers, and those in the last part only work against people who don't have sufficient understanding of how https works.
Which SIP application is it? I have been experimenting with Sipdroid myself, but I couldn't get it to work. Could be a problem with my SIP provider, but Ekiga works a lot better even when I am using Sipdroid and Ekiga from the same network.
No, read permission certainly does have a meaning for directories. Write permissions for a directory does pretty much what you would expect (some semantics are a bit more tricky if the sticky bit is set on the directory). Read permission means you can get a list of the names in the directory, execute permissions means you can do most things with those entries (except from those operations that require write permission). So, if you have read but no execute you can get a list of names in the directory, but you cannot do anything with them, you can't even tell if they are files or directories. If you have execute but no read, you can access everything as long as you know the name of it (or can guess the name).
The article doesn't contain enough information about A5/1 or the details of the attack for a crypto expert to explain exactly what he plan to do. However it does mention that he intend to create a rainbow table, so I can at least explain what a rainbow table is, and what the 128PB might mean. The article say it is a 64 bit encryption, but 128PB doesn't sound like the right size given a 64 bit encryption, the 128PB sounds more like a 54 bit encryption. And though it doesn't sound like a huge difference those 10 bits does mean a factor of 1024 times less work to brute force, and these days the difference between 54 and 64 bits may very well be the difference between feasible and not feasible to break. Of course in a few years 64 bits may be feasible to brute force as well.
Compressing 128PB down to 2-3TB doesn't sound realistic at first, but then consider that those 128PB are not just 128PB of random data, they are generated by a very simple algorithm. The entire code to generate those 128PB would probably fit in less than 1MB. But the time it would take to actually run the code for long enough to generate the 128PB is prohibitive. Also notice, that what is going to happen is not really a compression of the 128PB of data. The output of the algorithm is going to be a few TB of data, but that data can't actually be used to reproduce the original 128PB of data, which wouldn't be very interesting anyway. What you really want is a function that given some input can output the encryption key, and that can happen through a very simple table lookup, which would be very fast, but infeasible since very few people have the resources to store the complete 128PB lookup table. Instead you use a more complicated algorithm, which use 50.000 times less stored data, but OTOH may run 100.000 times (or even more) slower than the simple table lookup. But 100.000 table lookups would still only take a fraction of a second on a modern CPU.
Back to the rainbow tables. It is a tool to speed up the task of reversing a one way function. A one way function is a function that maps from one set of values to another set of values. The function is fast to compute in one direction, but there is no simple way to compute in the other direction. One example of a one way function is a hash function, which maps from strings of arbitrary lengths to the much smaller set of strings of one fixed length.
Let's assume our one way function is called f and maps from the set S to the set T. Then we can define a different function g, which maps from T to some interesting subset of S. For example it has been used in the past with a function that maps from 128 bit strings (outputs from MD5) to the set of passwords consisting of 7 alphanumeric characters (which is a subset of the possible inputs to MD5). If you combine g and f, you get a function mapping from T to T. If you start with a value in T and keep applying this combination, you will keep getting values in T.
Now you decide how many times in a row you will apply this combination, let's call that number n. A small n will produce very large rainbow tables, that may be faster to use. OTOH a large n will produce smaller rainbow tables that will be slower to use. This choice is the compromise mentioned in the article. He is probably going to use a value of n around 65536 or so.
Now you start producing chains (this is the large amount of work that this project will aim to distribute). You take some input in T, then you apply the combination of the two functions n times and get an output in T. You repeat that with a few hundred billion different values in T. The output will be a lot of pairs of values, from those pairs you create a lookup table.
Now assume you have a value x, which is the output of the one way function f, and you want to find out what the input may have been. Then you can apply the combination of functions n times and get n different values in T, look
You think that is bad? Some years back a seven year old girl got Mousehunt or so it said on the box that had been bought from a toy store. However the contents of the box turned out to be a porn movie called big nuts.