The judge did rule that interfaces are not copyrightable but that got overturned on appeal. He then asked the jury to decide if it was fair use. The jury voted yes to that.
Everything becomes a little bit cheaper because society now has to spend less money on launches. You have to pay less tax because the government get cheaper launches. Your internet may become a little cheaper because internet companies have to pay less for launches. You can get slightly more TV for the same money because broadcast companies pay less for launches. And so on.
You can also reverse the question. What would happen if launches became much more expensive? We would get less satellites and that might include less accurate weather forecasts, less service for farmers to optimise production, less optimal GPS service and so on.
Everyone benefits from this. Even the launches not made by SpaceX are going to be cheaper, because competitors have to do it cheaper to compete.
readObject is not something on the server, it is just a method signature defined by the serializable interface in the Java standard. The vulnerable code needs to be on the server of course, or there is nothing to abuse. The vulnerable code is in the Apache commons library, which has a class that implements serializable and therefore provides a readObject method, that can be abused.
But then you write something like "Serialized objects in Java is no difference than SOAP requests or JSON objects, or CORBA or other means to do RPC/RMI". But that is completely wrong in this context. The reason we have this bug is exactly because there is a difference from java serialization and all of the others that you mention. And that difference is that the serialization data includes arbitrary class names that allows the attacker to cause your code to load _any_ class that implements the serializable interface, no matter if that has anything to do with what you are working with here or not.
If you use JSON you will not have that. JSON can only cause strings, numbers, arrays and hashmaps to load.
This is also wrong: "Finally: serialized objects are just data, they contain no code. So there is nothing to execute. If you read the article, you see: the only code executed is the "readObject" method that already is on the server!!" - yes the exploit is in a readObject implementation, but that exploit allows the attacker to transmit arbitrary code and have it executed. Code that was in no way on the server already.
"First of all: there is no outside code executed when you transfer an object, the article is wrong with that. So you need a way to execute your code. The only way I can imagine is" - or the way the article describes. Which is not a derived object. He sends a serialization of a completely different object, namely the vulnerable class in Apache commons. The deserialization in Java just returns "Object" - there is no expectation here that the returned object be of the type that you, the programmer, expects. You will then of course get a class cast exception if you just cast it, or your code will notice something is not right if you do a isInstanceOf on it. But by then it is too late, he already had his custom code executed by Apache commons when the readObject method in there was called.
You need to know absolutely nothing about the system you want to attack. You only need two things, one is for the system to be vulnerable (=Apache commons needs to be on the classpath) and the other is that you need to find something the system serializes. You do not need to care about what it is that it serializes, because you will provide it with your hacked object, and the deserialization will fail but by then you already got what you want.
So if your web application does not use serialization the second prerequisite will fail and you are safe. But if you did something like putting a serialized object into a cookie, then you are done for.
Finally: serialized objects are just data, they contain no code. So there is nothing to execute. If you read the article, you see: the only code executed is the "readObject" method that already is on the server!!
Did YOU read the article? The serialized objects are just data - well except if someone made a readObject that as part of the deserialization process executes steps based on that data. Programs are just data.
The "bug" is that someone did exactly that and put it into a very common library. If you have that library on your classpath, and chances are very high that you do, then you have no defense against this. You lose the moment you try to deserialize the data. It does not matter that you are expecting the data to deserialize to something completely different.
Say you make a class called UserInfo and put that into a cookie using serialization. If you did that, you are a goner. There is no way you can deserialize that cookie without risking that somebody replaced the cookie value with serialized data from Apache commons. You will not know that it is not actually UserInfo data anymore until after he rooted your system.
The only solution is to a) do not deserialize data that could be modified by an adversary. Or b) if you must, make sure Apache commons is not on the classpath while you do so (could be done with a custom classloader).
Personally I would ditch the build in java serialization and use another serialization library, one which does not allow arbitrary class names in the serialization data. I switched to Scala long ago and in the Scala world most serialization libraries do not use reflection to (de)serialize, and therefore fulfill that requirement.
Port numbers is only useful and needed if you are dealing with carrier NAT. That is NAT performed by the ISP, such that multiple customers share the same ISP. This happens to be somewhat common with apartment networks.
If RIAA/MPAA records the address 2001:db8:a55:beef::2af6 only the "2001:db8:a55:beef" part is actually useful. The remaining part of the address will typically be a randomized privacy extension address. They are therefore still unable to prove which machine was used to download the content.
If you are one of the persons that want to use easy to remember addresses, you can still use privacy extensions. With IPv6 it is normal to have many address on each computer. You can have your easy to remember address (2001:db8:a55::2) that you use for ingoing connections. And the machine will prefer the random privacy extension address for outgoing connections (2001:db8:a55::9b43:82dd:2239:10bc - right now but in an hour it will be completely different).
baldur@ballerup1:~$ for i in google.com facebook.com www.netflix.com akamai.com cloudflare.com rackspace.com wikipedia.org; do ping6 -c1 -n $i | grep bytes; done PING google.com(2a00:1450:4005:801::1000) 56 data bytes 64 bytes from 2a00:1450:4005:801::1000: icmp_seq=1 ttl=50 time=28.8 ms PING facebook.com(2a03:2880:20:4f06:face:b00c:0:1) 56 data bytes 64 bytes from 2a03:2880:20:4f06:face:b00c:0:1: icmp_seq=1 ttl=43 time=191 ms PING www.netflix.com(2a01:578:3::36e4:ea94) 56 data bytes 64 bytes from 2a01:578:3::36e4:ea94: icmp_seq=1 ttl=46 time=38.0 ms PING akamai.com(2a02:26f0:103:186::22df) 56 data bytes 64 bytes from 2a02:26f0:103:186::22df: icmp_seq=1 ttl=54 time=22.3 ms PING cloudflare.com(2400:cb00:2048:1::c629:d59d) 56 data bytes 64 bytes from 2400:cb00:2048:1::c629:d59d: icmp_seq=1 ttl=57 time=10.6 ms PING rackspace.com(2001:4801:1221:101:1c10:0:f5:116) 56 data bytes 64 bytes from 2001:4801:1221:101:1c10:0:f5:116: icmp_seq=1 ttl=43 time=127 ms PING wikipedia.org(2620:0:862:ed1a::1) 56 data bytes 64 bytes from 2620:0:862:ed1a::1: icmp_seq=1 ttl=52 time=20.7 ms
The CDNs in there means that you will get some content over IPv6 even from sites that are not IPv6 enabled as such.
IPv6 Neighbour Discovery protocol (ND) https://tools.ietf.org/html/rf... is the protocol used by IPv6 hosts to find each other. It is the IPv6 equivalent of ARP. And ND is based on multicast. Without multicast, nothing would work with IPv6.
An IPv4 host needs to use broadcast ARP packets to every host on the same network. This was fixed in IPv6, so each host uses the last 32 bits of its address as a multicast group. When you need to contact someone, you will take the last 32 bits of his address and then multicast your ND packets to that multicast group. That way only hosts that share the same last 32 bits will receive the ND packet. This dramatically reduces the amount of broadcast/multicast chatter received by each host.
The downside is that it only works on networks with MLD enabled switches. That is very rare. Without MLD the system will fall back to broadcast.
But just to point out that you are wrong to believe that multicast is experimental when in fact it was baked in from the very start.
Your computer will generate a random IPv6 address and change that random address at regular intervals (typically a few hours before it changes). Therefore they will be unable to track the exact computer, because there is no way to know which computer had that random address at the time.
They will get you anyway due to cookies and device fingerprinting, but that is no different than the situation with IPv4 and NAT.
Also with carrier NAT ISPs in most countries are by law required to record the port numbers assigned to each user. Your IP might be shared with multiple other users, but as long they also recorded the port number, they will be able to find the user. RIAA and MPAA knows this - I get a ton of email from them every day complaining about users that download their stuff with Bittorrent and every complaint includes port numbers.
"This document describes a stateless, transport-agnostic IPv6-to-IPv6
Network Prefix Translation (NPTv6) function that provides the
address-independence benefit associated with IPv4-to-IPv4 NAT
(NAPT44) and provides a 1:1 relationship between addresses in the
"inside" and "outside" prefixes, preserving end-to-end reachability
at the network layer."
Although personally I believe it is seldom needed. In practice a IPv6 home network can renumber every device within 30 seconds of the ISP changing the prefix on you. That is less time than it takes for your CPE router to reboot.
Nope, all three protocols will work fine with any prefix size. Only SLAAC need a/64 prefix
If you did a/120 you would use RA to tell your network about it. You would then need to set the managed config flag, so your devices can use DHCPv6 to acquire an address. After getting an address through DHCPv6 the devices will use the DAD process to check that the address is unused. And they will use ND to be able to communicate with other devices.
The majority of internet service providers will give you a/48 prefix. Meaning that you decide what to do with the remaining 80 bits. If you make them all zero, your IPv6 address can indeed be shorter than the typical IPv4.
Example:
2001:db8:123:: (that would be your router) 2001:db8:123::2 (that would be your web server or whatever). 2001:db8:123::3 (that would be your mail server or whatever).
Compare to:
198.51.100.250 (that would be your router - and also your web/mail server because it is all you got).
Blocks less than a/24 are not routable on the Internet. For some reason it was RIPE that tested that with a loaned block from ARIN.
One can hope that ARIN will recognize the need to be able to route this on the internet as sufficient reason to get a/24 instead of a/28.
There is one other difference to the RIPE policy and that is the IPv6 requirement. There is no such requirement by RIPE. You will get your/22 from RIPE and you can continue to ignore IPv6 and just use it with carrier NAT or whatever. RIPE will ask you to take an IPv6 assignment as well, but they do not ask if you are going to use it for anything.
You are wrong. My router does have DHCPv6 and so does every OS (Linux, Mac and Windows) on my network.
You will find that basically 100% of the new generation routers (those with 802.11ac radios) come with full fledged IPv6 support these days. Including DHCPv6 support.
As to the ISP that seems to depend entirely on what country you live in. Some countries have very high penetration now. The rest of the world will follow.
They wont because my ISP makes static allocations to every customer. But if you have another ISP with a poor policy, then you can use a private range such as fd00::/64 for your internal network.
fd00::2 is shorter than 192.168.1.2 if we are still at that...
Yes you are supposed to put in something random in the fd00 style address. But nothing stops you from ignoring that. It is just so that your VPN to your employer does not collide unnecessary with your home network, but if both of you choose to use the same range, you are no worse off than if the same thing happened on IPv4.
For the average customer this is no issue however. They are in don't care about IP-addresses boat. If the ISP changes your prefix, your internal network will just renumber too and nobody notices.
The CEO can do one call to CloudFlare or any other number of content delivery networks. They will happily put a IPv6 to IPv4 proxy in front of his servers, without the missing slashdot.org engineers needing to change anything at all.
Notice how it is _exactly_ the length of your proposal? I also happen to be able to remember it...
Ok, it is the address of my router, from where I can do port forwards etc, just like we used to do. So if you ssh into that, you will get to my server.
My other devices have longer addresses. Such as 2a00:7660:349::2. Yes there is a thing called DHCPv6 that allows one to assign short addresses to devices.
And because the ISP only controls the first 48 bits of the address, every device of mine gets to have an IP address and I was the one that decided the parts that might need to be remembered (the "2" from before).
It is true that most people will just let their network do auto configuration, which will then result in random and long addresses. That is because these days people generally do not care about IP-addresses. But it is your option - you can get it nice and clean if you are one of the few that cares.
You found enough/8 blocks to distribute one or two to each region. It would be gone within the week.
APNIC and RIPE have been out for years now and ARIN is building up a waiting list. The demand did not just stop - there is a huge unfilled demand there that will soak up any stray addresses you can find.
But the real problem is that there is no legal framework to force these companies to stop using the addresses. How much worth is an IP address that can not be used by an Apple device?
Each generator is constantly trying to run a little faster than the grid. This result in a current from the generator. If the generator only matched the grid exactly, there would be no current which means there would be no power generated.
The grid frequency will in fact change according to load. Look it up. If the grid is overloaded, the frequency drops. This happens because the voltage difference between the generator and the grid is just another way to view the fact that the generator is a bit a head. A bigger voltage difference means the generator is further ahead. A bigger voltage difference also means more current and more power is being drawn out of the generator, which it can not hold up. Therefore the generator will slow down until the voltage difference between the grid and the generator matches the power rating of the generator.
The reverse is also true. If there is less demand than power generated, the voltage will rise and the generators will start skipping further ahead. The frequency goes up.
Most generators need the grid to pace them correctly. They can not run without the grid. This creates big trouble when the grid crashes and none of the powerplants are able to start up isolated. Usually they have a few generators that have the special ability to boot the grid.
Large generators have inertia. They will not change frequency quickly. This is important to keep the grid stable. Small generators, such as those in windmills, do not have this property. This means you can not run a grid on windmills alone. In some parts of Germany this is sometimes a big problem.
Network, gateway and broadcast are still IP addresses so the company does indeed own 512 addresses.
Second, it is not true that you can not use 3 IP addresses. The most obvious is the gateway address - can the computer doing the routing not also run a web server? Does in fact not most home routers run various services, including a web server, dhcp client, NAT etc?
The subnet would be routed and usually the IP address used for routing would be provided by the IP transit company. As a routed subnet there is nothing that forces a particular subnetting scheme. They could deploy it as a big/23 subnet. Or as a bunch of/30 subnets, allowing only 128 "usable" IP addresses.. But they could equally also deploy/32 addresses and this technique would allow you to use all 512 IP addresses for hosts. Or it could be used as a NAT pool, again allowing you to use all addresses including the first and last address in the series.
As to how you deploy/32 addresses you can do that by DHCP or manually - on Linux eg:
# add the/32 address ip addr add 123.1.2.0/32 dev eth0 # add a host route for the IP that will be used for gateway ip route add 10.0.0.1/32 dev eth0 # add default gateway route ip route add default via 10.0.0.1
Notice that you can use a completely different subnet for gateway, such as 10.0.0.1.
There is only a very small window where a bad cable gets you bit errors, but not so many that the networking becomes completely unusable. If just 1% of the packets are dropped, your effective TCP transmission rate will drop do 1 Mbit/s or lower.
If you are doing a file download from your NAS you will be doing a lot of 1,500 bytes ethernet frames. That is 15,000 bits per frame. If just one if those bits fail, the packet is dropped. Less than 1% of the packets can be dropped before you will notice that something is seriously wrong with your network, that means less than 1 error bit in 1,500,000 can be accepted. That is so close to zero, that in most cases you will go from perfect network directly to "this does not work" as soon as the signal degrades below the point where there are no bit errors.
You can not have jitter at the bit level and still receive the signal error free. It is ethernet and you will get your jitter simply because there is other traffic on the cable, so there is no guarantee that the line is free for immediate transmission of your packet. Even with QoS you will have to wait until the current transmitting packet is done.
But jitter is a non issue because all applications that receive audio via ethernet will have buffers to deal with it.
And last, because ethernet is a packet network, you will need to buffer your audio so you can collect enough bytes to send a packet. If you had no buffer, you would be sending packets with 1 sample (4 bytes assuming 16 bit stereo). The overhead of that would be astronomical plus you would indeed die the jitter death.
Slashdot Mirror
The judge did rule that interfaces are not copyrightable but that got overturned on appeal. He then asked the jury to decide if it was fair use. The jury voted yes to that.
How does that affect me?
Everything becomes a little bit cheaper because society now has to spend less money on launches. You have to pay less tax because the government get cheaper launches. Your internet may become a little cheaper because internet companies have to pay less for launches. You can get slightly more TV for the same money because broadcast companies pay less for launches. And so on.
You can also reverse the question. What would happen if launches became much more expensive? We would get less satellites and that might include less accurate weather forecasts, less service for farmers to optimise production, less optimal GPS service and so on.
Everyone benefits from this. Even the launches not made by SpaceX are going to be cheaper, because competitors have to do it cheaper to compete.
Better than being identified as a phone or giraffe.
IPv6 please. It is easy. A tech site for geeks should have had IPv6 a decade ago.
readObject is not something on the server, it is just a method signature defined by the serializable interface in the Java standard. The vulnerable code needs to be on the server of course, or there is nothing to abuse. The vulnerable code is in the Apache commons library, which has a class that implements serializable and therefore provides a readObject method, that can be abused.
But then you write something like "Serialized objects in Java is no difference than SOAP requests or JSON objects, or CORBA or other means to do RPC/RMI". But that is completely wrong in this context. The reason we have this bug is exactly because there is a difference from java serialization and all of the others that you mention. And that difference is that the serialization data includes arbitrary class names that allows the attacker to cause your code to load _any_ class that implements the serializable interface, no matter if that has anything to do with what you are working with here or not.
If you use JSON you will not have that. JSON can only cause strings, numbers, arrays and hashmaps to load.
This is also wrong: "Finally: serialized objects are just data, they contain no code. So there is nothing to execute. If you read the article, you see: the only code executed is the "readObject" method that already is on the server!!" - yes the exploit is in a readObject implementation, but that exploit allows the attacker to transmit arbitrary code and have it executed. Code that was in no way on the server already.
"First of all: there is no outside code executed when you transfer an object, the article is wrong with that. So you need a way to execute your code. The only way I can imagine is" - or the way the article describes. Which is not a derived object. He sends a serialization of a completely different object, namely the vulnerable class in Apache commons. The deserialization in Java just returns "Object" - there is no expectation here that the returned object be of the type that you, the programmer, expects. You will then of course get a class cast exception if you just cast it, or your code will notice something is not right if you do a isInstanceOf on it. But by then it is too late, he already had his custom code executed by Apache commons when the readObject method in there was called.
You need to know absolutely nothing about the system you want to attack. You only need two things, one is for the system to be vulnerable (=Apache commons needs to be on the classpath) and the other is that you need to find something the system serializes. You do not need to care about what it is that it serializes, because you will provide it with your hacked object, and the deserialization will fail but by then you already got what you want.
So if your web application does not use serialization the second prerequisite will fail and you are safe. But if you did something like putting a serialized object into a cookie, then you are done for.
Finally: serialized objects are just data, they contain no code. So there is nothing to execute. If you read the article, you see: the only code executed is the "readObject" method that already is on the server!!
Did YOU read the article? The serialized objects are just data - well except if someone made a readObject that as part of the deserialization process executes steps based on that data. Programs are just data.
The "bug" is that someone did exactly that and put it into a very common library. If you have that library on your classpath, and chances are very high that you do, then you have no defense against this. You lose the moment you try to deserialize the data. It does not matter that you are expecting the data to deserialize to something completely different.
Say you make a class called UserInfo and put that into a cookie using serialization. If you did that, you are a goner. There is no way you can deserialize that cookie without risking that somebody replaced the cookie value with serialized data from Apache commons. You will not know that it is not actually UserInfo data anymore until after he rooted your system.
The only solution is to a) do not deserialize data that could be modified by an adversary. Or b) if you must, make sure Apache commons is not on the classpath while you do so (could be done with a custom classloader).
Personally I would ditch the build in java serialization and use another serialization library, one which does not allow arbitrary class names in the serialization data. I switched to Scala long ago and in the Scala world most serialization libraries do not use reflection to (de)serialize, and therefore fulfill that requirement.
It may not be worse but it will have programmed sense, so it will refuse to attempt it.
Port numbers is only useful and needed if you are dealing with carrier NAT. That is NAT performed by the ISP, such that multiple customers share the same ISP. This happens to be somewhat common with apartment networks.
If RIAA/MPAA records the address 2001:db8:a55:beef::2af6 only the "2001:db8:a55:beef" part is actually useful. The remaining part of the address will typically be a randomized privacy extension address. They are therefore still unable to prove which machine was used to download the content.
If you are one of the persons that want to use easy to remember addresses, you can still use privacy extensions. With IPv6 it is normal to have many address on each computer. You can have your easy to remember address (2001:db8:a55::2) that you use for ingoing connections. And the machine will prefer the random privacy extension address for outgoing connections (2001:db8:a55::9b43:82dd:2239:10bc - right now but in an hour it will be completely different).
There is also some big sites that are available:
baldur@ballerup1:~$ for i in google.com facebook.com www.netflix.com akamai.com cloudflare.com rackspace.com wikipedia.org; do ping6 -c1 -n $i | grep bytes; done
PING google.com(2a00:1450:4005:801::1000) 56 data bytes
64 bytes from 2a00:1450:4005:801::1000: icmp_seq=1 ttl=50 time=28.8 ms
PING facebook.com(2a03:2880:20:4f06:face:b00c:0:1) 56 data bytes
64 bytes from 2a03:2880:20:4f06:face:b00c:0:1: icmp_seq=1 ttl=43 time=191 ms
PING www.netflix.com(2a01:578:3::36e4:ea94) 56 data bytes
64 bytes from 2a01:578:3::36e4:ea94: icmp_seq=1 ttl=46 time=38.0 ms
PING akamai.com(2a02:26f0:103:186::22df) 56 data bytes
64 bytes from 2a02:26f0:103:186::22df: icmp_seq=1 ttl=54 time=22.3 ms
PING cloudflare.com(2400:cb00:2048:1::c629:d59d) 56 data bytes
64 bytes from 2400:cb00:2048:1::c629:d59d: icmp_seq=1 ttl=57 time=10.6 ms
PING rackspace.com(2001:4801:1221:101:1c10:0:f5:116) 56 data bytes
64 bytes from 2001:4801:1221:101:1c10:0:f5:116: icmp_seq=1 ttl=43 time=127 ms
PING wikipedia.org(2620:0:862:ed1a::1) 56 data bytes
64 bytes from 2620:0:862:ed1a::1: icmp_seq=1 ttl=52 time=20.7 ms
The CDNs in there means that you will get some content over IPv6 even from sites that are not IPv6 enabled as such.
IPv6 Neighbour Discovery protocol (ND) https://tools.ietf.org/html/rf... is the protocol used by IPv6 hosts to find each other. It is the IPv6 equivalent of ARP. And ND is based on multicast. Without multicast, nothing would work with IPv6.
An IPv4 host needs to use broadcast ARP packets to every host on the same network. This was fixed in IPv6, so each host uses the last 32 bits of its address as a multicast group. When you need to contact someone, you will take the last 32 bits of his address and then multicast your ND packets to that multicast group. That way only hosts that share the same last 32 bits will receive the ND packet. This dramatically reduces the amount of broadcast/multicast chatter received by each host.
The downside is that it only works on networks with MLD enabled switches. That is very rare. Without MLD the system will fall back to broadcast.
But just to point out that you are wrong to believe that multicast is experimental when in fact it was baked in from the very start.
You need to read up on IPv6 privacy extensions: https://tools.ietf.org/html/rf...
Your computer will generate a random IPv6 address and change that random address at regular intervals (typically a few hours before it changes). Therefore they will be unable to track the exact computer, because there is no way to know which computer had that random address at the time.
They will get you anyway due to cookies and device fingerprinting, but that is no different than the situation with IPv4 and NAT.
Also with carrier NAT ISPs in most countries are by law required to record the port numbers assigned to each user. Your IP might be shared with multiple other users, but as long they also recorded the port number, they will be able to find the user. RIAA and MPAA knows this - I get a ton of email from them every day complaining about users that download their stuff with Bittorrent and every complaint includes port numbers.
Try "Network Prefix Translation" instead: https://tools.ietf.org/html/rf...
"This document describes a stateless, transport-agnostic IPv6-to-IPv6
Network Prefix Translation (NPTv6) function that provides the
address-independence benefit associated with IPv4-to-IPv4 NAT
(NAPT44) and provides a 1:1 relationship between addresses in the
"inside" and "outside" prefixes, preserving end-to-end reachability
at the network layer."
Although personally I believe it is seldom needed. In practice a IPv6 home network can renumber every device within 30 seconds of the ISP changing the prefix on you. That is less time than it takes for your CPE router to reboot.
Nope, all three protocols will work fine with any prefix size. Only SLAAC need a /64 prefix
If you did a /120 you would use RA to tell your network about it. You would then need to set the managed config flag, so your devices can use DHCPv6 to acquire an address. After getting an address through DHCPv6 the devices will use the DAD process to check that the address is unused. And they will use ND to be able to communicate with other devices.
The majority of internet service providers will give you a /48 prefix. Meaning that you decide what to do with the remaining 80 bits. If you make them all zero, your IPv6 address can indeed be shorter than the typical IPv4.
Example:
2001:db8:123:: (that would be your router)
2001:db8:123::2 (that would be your web server or whatever).
2001:db8:123::3 (that would be your mail server or whatever).
Compare to:
198.51.100.250 (that would be your router - and also your web/mail server because it is all you got).
Blocks less than a /24 are not routable on the Internet. For some reason it was RIPE that tested that with a loaned block from ARIN.
One can hope that ARIN will recognize the need to be able to route this on the internet as sufficient reason to get a /24 instead of a /28.
There is one other difference to the RIPE policy and that is the IPv6 requirement. There is no such requirement by RIPE. You will get your /22 from RIPE and you can continue to ignore IPv6 and just use it with carrier NAT or whatever. RIPE will ask you to take an IPv6 assignment as well, but they do not ask if you are going to use it for anything.
You are wrong. My router does have DHCPv6 and so does every OS (Linux, Mac and Windows) on my network.
You will find that basically 100% of the new generation routers (those with 802.11ac radios) come with full fledged IPv6 support these days. Including DHCPv6 support.
As to the ISP that seems to depend entirely on what country you live in. Some countries have very high penetration now. The rest of the world will follow.
They wont because my ISP makes static allocations to every customer. But if you have another ISP with a poor policy, then you can use a private range such as fd00::/64 for your internal network.
fd00::2 is shorter than 192.168.1.2 if we are still at that...
Yes you are supposed to put in something random in the fd00 style address. But nothing stops you from ignoring that. It is just so that your VPN to your employer does not collide unnecessary with your home network, but if both of you choose to use the same range, you are no worse off than if the same thing happened on IPv4.
For the average customer this is no issue however. They are in don't care about IP-addresses boat. If the ISP changes your prefix, your internal network will just renumber too and nobody notices.
The CEO can do one call to CloudFlare or any other number of content delivery networks. They will happily put a IPv6 to IPv4 proxy in front of his servers, without the missing slashdot.org engineers needing to change anything at all.
Actually my IPv6 address is:
2a00:7660:349::
Notice how it is _exactly_ the length of your proposal? I also happen to be able to remember it...
Ok, it is the address of my router, from where I can do port forwards etc, just like we used to do. So if you ssh into that, you will get to my server.
My other devices have longer addresses. Such as 2a00:7660:349::2. Yes there is a thing called DHCPv6 that allows one to assign short addresses to devices.
And because the ISP only controls the first 48 bits of the address, every device of mine gets to have an IP address and I was the one that decided the parts that might need to be remembered (the "2" from before).
It is true that most people will just let their network do auto configuration, which will then result in random and long addresses. That is because these days people generally do not care about IP-addresses. But it is your option - you can get it nice and clean if you are one of the few that cares.
You found enough /8 blocks to distribute one or two to each region. It would be gone within the week.
APNIC and RIPE have been out for years now and ARIN is building up a waiting list. The demand did not just stop - there is a huge unfilled demand there that will soak up any stray addresses you can find.
But the real problem is that there is no legal framework to force these companies to stop using the addresses. How much worth is an IP address that can not be used by an Apple device?
Each generator is constantly trying to run a little faster than the grid. This result in a current from the generator. If the generator only matched the grid exactly, there would be no current which means there would be no power generated.
The grid frequency will in fact change according to load. Look it up. If the grid is overloaded, the frequency drops. This happens because the voltage difference between the generator and the grid is just another way to view the fact that the generator is a bit a head. A bigger voltage difference means the generator is further ahead. A bigger voltage difference also means more current and more power is being drawn out of the generator, which it can not hold up. Therefore the generator will slow down until the voltage difference between the grid and the generator matches the power rating of the generator.
The reverse is also true. If there is less demand than power generated, the voltage will rise and the generators will start skipping further ahead. The frequency goes up.
Most generators need the grid to pace them correctly. They can not run without the grid. This creates big trouble when the grid crashes and none of the powerplants are able to start up isolated. Usually they have a few generators that have the special ability to boot the grid.
Large generators have inertia. They will not change frequency quickly. This is important to keep the grid stable. Small generators, such as those in windmills, do not have this property. This means you can not run a grid on windmills alone. In some parts of Germany this is sometimes a big problem.
Network, gateway and broadcast are still IP addresses so the company does indeed own 512 addresses.
Second, it is not true that you can not use 3 IP addresses. The most obvious is the gateway address - can the computer doing the routing not also run a web server? Does in fact not most home routers run various services, including a web server, dhcp client, NAT etc?
The subnet would be routed and usually the IP address used for routing would be provided by the IP transit company. As a routed subnet there is nothing that forces a particular subnetting scheme. They could deploy it as a big /23 subnet. Or as a bunch of /30 subnets, allowing only 128 "usable" IP addresses.. But they could equally also deploy /32 addresses and this technique would allow you to use all 512 IP addresses for hosts. Or it could be used as a NAT pool, again allowing you to use all addresses including the first and last address in the series.
As to how you deploy /32 addresses you can do that by DHCP or manually - on Linux eg:
# add the /32 address
ip addr add 123.1.2.0/32 dev eth0
# add a host route for the IP that will be used for gateway
ip route add 10.0.0.1/32 dev eth0
# add default gateway route
ip route add default via 10.0.0.1
Notice that you can use a completely different subnet for gateway, such as 10.0.0.1.
Its 512. Come, count with me:
1
2
4
8
16
32
64
128
256
512
There is only a very small window where a bad cable gets you bit errors, but not so many that the networking becomes completely unusable. If just 1% of the packets are dropped, your effective TCP transmission rate will drop do 1 Mbit/s or lower.
If you are doing a file download from your NAS you will be doing a lot of 1,500 bytes ethernet frames. That is 15,000 bits per frame. If just one if those bits fail, the packet is dropped. Less than 1% of the packets can be dropped before you will notice that something is seriously wrong with your network, that means less than 1 error bit in 1,500,000 can be accepted. That is so close to zero, that in most cases you will go from perfect network directly to "this does not work" as soon as the signal degrades below the point where there are no bit errors.
You can not have jitter at the bit level and still receive the signal error free. It is ethernet and you will get your jitter simply because there is other traffic on the cable, so there is no guarantee that the line is free for immediate transmission of your packet. Even with QoS you will have to wait until the current transmitting packet is done.
But jitter is a non issue because all applications that receive audio via ethernet will have buffers to deal with it.
And last, because ethernet is a packet network, you will need to buffer your audio so you can collect enough bytes to send a packet. If you had no buffer, you would be sending packets with 1 sample (4 bytes assuming 16 bit stereo). The overhead of that would be astronomical plus you would indeed die the jitter death.