Most speedtest servers are hosted on 1 gigabit/s which means you will probably never be able to get a clean 1 gigabit/s reading from those. That would require that you got the server all by yourself and that wont happen.
We are an ISP that sell gigabit. We host our own speedtest.net server on a 10 gigabit/s. It might be considered "cheating" as the user will only be measuring our internal network. But there is simply no other speedtest server nearby that is able to give consistent good readings. There are a couple that will give you ok readings ("almost 1 gig") but that depends on the time of the day and you might have to try several times.
And no, our transit connections are not congested. However ISPs that do not market themselves as selling 1 gig or more will have no reason to establish 10 gigabit/s at all interconnections. But that also means traffic to them will be limited by the interconnection.
Take a look at any IX member list and notice how many companies have only 1 gbps or slower ports. Our users will never get 1 gig to those guys if the traffic goes that route. Remember there will always be other traffic on the port as well.
However, if a user has traffic to multiple destinations he will usually be able to take full advantage. So it is good for families. You will never be slowed down by what others are doing in your household.
I work for an ISP. The way it works is, the 2 isp's have a free peering agreement... Every month or 3 they compare traffic and true up. You ate up 100gig more than we did? You party us X. And vice versa.
I own an ISP. This is not the way it works at all.
Peering policy is actually a rather complex topic. How it works depends on what kind of ISP you are and your size. Small ISPs want to peer no matter what. Large ISPs typically do not want to peer at all. The balanced peering requirement is a poor excuse to say no to peering.
As a small ISP we want to peer with all and everything. This is because any byte transmitted over a free peering is a byte that did not have to go via our paid transit circuit. It does not really matter in what direction that byte is going.
As a residential ISP the majority of our traffic is download. The transit cost is determined by the larger of upload and download. If we can get rid of some download, we will save good money. Netflix is offering to bring some of that download to us for free.
It is very asymmetric and it is a very good deal for both companies. It is a win-win.
So why do large ISPs not want to do this? Because they can get away with forcing everyone to pay to deliver traffic to them. It is no longer a win for them if they think they can get Netflix to be a paying customer. Nor if they already have free peering with the big transit providers, because then they are already getting the stream for free.
Why do mid sized ISPs not want to peer with small ISPs? If the mid sized ISP has a peering agreement with the transit provider of the small ISP, they are already getting the traffic for free. So there is no gain for them. On the other hand, the mid sized ISP might believe the smaller ISP could become a transit customer and you never peer with your customers or potential customers.
But instead of coming clear and tell the real reason, you will typically get the balanced peering requirement quote instead.
In truth balanced peering is not really possible nor desirable for a residential ISP. Only other residential ISP would have balance with us but there will be very little traffic. Just a little bit of bittorrent etc. As a residential ISP we need to peer with content providers, hosting companies and the like.
The only problem is that multicast is not actually deployed on the internet, so you can only use it locally. Sure some ISPs use it for their own TV streaming, but third parties are locked out from using it.
You assume the gears have no imperfections. You will find that it is not actually giving you the expected accuracy. Just a little bit of slack in the final gear could equal thousands of revolutions in the input gear.
You need torque to turn this thing. Due to the extreme reduction, the needed torque has little if any relation to what you put at the output. Instead it is just the internal friction of the plastic gears. Which means there is a point where further reduction does not make it any easier to turn.
You need strength in the part to use the output torque. Due to the extreme reduction, output torque is practically limited only to the point where the plastic gears break. There is a point where further reduction does not give you anything, because you are already past the point where the gears break.
Clearly this thing is way past both of those points.
You can not get infinite accuracy either. At some point the output shaft will stop moving smoothly compared to input, but instead move in a way determined by imperfections in the gears.
But it will only be used for "compatibility" - to communicate with IPv4 hosts that have not yet been upgraded to IPv6. If you think about it, there are no reason to deploy devices that can understand "quints" as that is just as big an upgrade to the IP stack as switching to IPv6.
Your home router will run the A+P function. It will share an IP address with other customers at your ISP. You will be assigned a port range with that shared IP address. The router will simply do NAT, so your devices on the home network do not need to know anything about this.
At some point you will find that it sucks not to be able to run ssh on port 22 and http on port 80. Therefore your helpful ISP has also provided you with IPv6, where no such limitations apply.
Also the trick only works with UDP and TCP, as other IP protocols do not use ports.
Replying to the guys that said it is illegal to sell: not only is it legal, but several of the internet registries put up their own marketplace for trading IP address space.
That is not what should happen if you have it configured proper.
Say your prefix is 2001:db8:1::/48
Your LAN is 2001:db8:1:1::/64 Your WIFI is 2001:db8:1:2::/64
Your laptop has 2001:db8:1:1::10 on the LAN and 2001:db8:1:2::20 on the WIFI.
Now if you type ping6 2001:db8:1:1::42 it will automatically prefer the LAN interface and use the 2001:db8:1:1::10 IP address. It will not use the WIFI address unless you force it.
On the other hand if you ping6 2001:db8:1:2::42 it will select the WIFI interface and use 2001:db8:1:2::20 as source address.
If you ping something on the internet or if you ping 2001:db8:1:3::99 (assuming the laptop is not connected directly to that), it will first select an outgoing interface (either LAN or WIFI) and then pick the source address from that interface. Again unless you force it to do something different. These are the default address selection rules.
Typically your firewall is also the device that is handling the DHCP-PD with upstream and assigning/64s to your downstream routers or to different ports on the device. It will just work. It will not think that the traffic is spoofed. It will also do connection tracking and know exactly what is spoofed and what is not.
Devices will pick the correct IP from the outgoing interface. If your laptop has a Wifi connection, it will use the Wifi address when initiating connections that way. And the LAN address when sending out traffic on the wired network.
Applications can override that behavior but then you are dealing with misconfiguration or broken applications.
Trouble with devices connected to two subnets (links in IPv6 terms) at the same time are basically the same with IPv4 and IPv6.
Android does not support DHCPv6 at all. Proposing that they should implement IA_PD but not IA_NA is silly. Doing that might very well break PD on networks where there is a requirement that the next hob for the PD is known and stable. Such as ours...
What you can't do? You can't do tethering except on 3G/4G networks. Why you would want to? Dunno, but I notice that not every Android device is a phone. There could be use cases for that.
Also there are universities and large companies that simply wont let you do SLAAC. I have no experience running such networks, so I can not tell if they are right in doing that. I imagine they could have some of the same issues that we have in our ISP network (ND cache exhaustion etc). A simple defense could be to use a/120 or/112 with DHCPv6.
I do not know about APNIC, but RIPE accepts/48 assignments to end users. All ISPs in my country, which are doing IPv6 (which few of them are), are handing out/48 to users. So that is kind of the standard here.
Even the smallest ISP can get a/29 allocation from RIPE. That is a half a million of/48 assignments to give on to end users.
The problem with the idea of a global hierarchy routing is that the internet is not a hierarchy. BGP simply does not work like that. Solving that (if it needs solving) requires something more. One proposal is LISP.
Try using tethering while you have that Android on Wifi (tethering using bluetooth to a laptop). That wont work because that requires DHCPv6. Why would you want to? I don't know, but that is what is broken here.
It works while using cellular internet because they effectively have an alternative to DHCP-PD to assign a/64 prefix to the phone. They new LTE standard is switching to DHCP-PD so I wonder what Google will do then.
Except for cellular carriers, almost all ISPs are assigning multiple/64. Most are doing either/56 or/48.
The way to structure your internal network with three subnets is very simple. You will use three/64 out of the/56 or/48 that you got from your ISP.
There are many reasons that ISPs will not be assigning/64 or smaller. That is simply very hard on the ISP equipment. So have no fear, that will not become common.
Privacy extensions is an extension to SLAAC. All major operating systems come with privacy extensions enabled by default, which means they will do a dosen of adresses per device. If you enable SLAAC in the provider network and do not use DHCPv6-PD, most CPEs will bridge IPv6. That means the ISP switch/router has to track every single device inside your household multiplied by number of addresses used for privacy extensions.
But it is a problem even with no device actually using the address. If someone starts mapping your address space (eg. using nmap) the ISP router has to start NDP discovery on every single address that someone sends a ICMP ping to. There is no way the ISP router can know that there is no device with that address. The only defense is to limit the number of active cache entries per customer, but then you just made it very simple to DoS the customer with trivial amount of ICMP traffic.
For this reason the sane way to implement IPv6 as to do DHCPv6-PD and assign either 0 or 1 IPv6 address on the link interface. Zero is possible because IPv6 can use link local addresses for routing, but it will screw up your traceroute and arguably it prevents the CPE from sending back mandatory ICMP packets such as MTU changes.
I work for a (smallish) ISP so let me tell you why you will simply not get any IPv6 service without DHCPv6 on our network.
It has nothing at all to do with being IPv4 old-timers. That is just you not understanding the complexity of the world out there. Our network was build from the start with the idea that IPv6 is the future.
We use DHCPv6 to provide every user with his own/48 prefix. Yes you said that DHCPv6 is a great solution for prefixes. But we also use it to deliver a/128 to go with that prefix. We need this to have a stable and predictable address that we can use as next hob for your shiny new prefix.
We had this very same debate on the NANOG mailing list. Some people there asked why does your routers not sniff the DHCPv6 packet and add the route dynamically? Two reasons. One, that is not in any standard, so our vendor did not implement it. Two, it does not work if you have router redundancy (how would the backup router know the route?).
There are more reasons an ISP would not want to use SLAAC. It exposes 2**64 addresses to the ISP network access routers. This can harm the network in many different ways and you simply do not want your ND caches to be full of that crap. You want to use as few slots in the shared ND cache per user. Therefore you are going to disable SLAAC on the customer edge and use some other mechanism. One guy suggested not using GUA on the customer links and only use link local addressing here. We choose to use/128 DHCPv6 assigned addresses. In either case, GUA-SLAAC is a fail in the provider network.
SLAAC is great inside the household of our customers. But we leave that decision to the customer and his choice of CPE-router.
The problem with Android is that it should really be able to act like a CPE for tethering purposes. Therefore is should be able to accept our CPE configuration. Android should also be able to ask for a prefix to be sub-delegated from the house CPE and it should accept that this might come with extra addresses that will be used for routing or for other purposes.
1) IPv4 vs IPv6 has nothing to do with ASN. If you do have an ASN you will be using the same ASN for both protocols. With 32 bit ASN now in wide use, there is nothing limiting you from applying for one. Get your own/48 prefix with it.
2) IPv6 has NAT.
3) Multihoming is perfectly possible using IPv6. There is no rule telling you not to do it exactly like you always did with IPv4.
4) There is no rule that say you can not split a/64. You can split it down to/128 if you want. The only thing that breaks is SLAAC but you can still use DHCPv6 or static/manual configuration.
5) All major ISPs are giving out/56 or more address space, so you have no need to split a/64.
6) All major operating systems use privacy extension enabled by default, so you MAC will not be exposed when you surf the net. Your device will be no more tracked than with IPv4-NAT since it changes address all the time.
All IPv6 gives you are options. There are now more ways to do the above things. But in no way did you lose the ability to keep doing things like yesterday.
::ffff:a.b.c.d is what is used inside programs that want to use just one socket type (IPv6) to handle both protocols. I believe your OS might very well refuse to configure that on an interface.
I admit to abuse fd00::/8 but not any more than what the IPv4 think brings you anyway. Using the very first network of fd00::/8 will bring you the pain of colliding with everyone else that did exactly the same, but you will not likely collide with someone who cared enough to generate a global unique ULA prefix. This is 100% equal to having the majority of home networks on the same/24 network (192.168.1.x). You lose the advantage that IPv6 was supposed to get you, but some people here seems to be dead set to lose all that if they can, just because they don't like hex.
Oh I see. You did not get the fact that when I type ping6 2001:778:0:ffff:64:0:8.8.8.8 on my IPv6 only computer, then I am in fact pinging 8.8.8.8 which happens to be a real IPv4 only server out there. You said why didn't they embed the old number plan in the new one - and they did. Multiple times actually.
If I have a NAT64 device on my local network, then my IPv6 only machine can in fact communicate with IPv4 only devices. The packets will go through the NAT64 device, because there simply is no other way - and that is a technical problem, not administrative.
We have seen a zillion proposals for alternative "IPv7" plans including yours. None have explained how that scheme would allow an old IPv4 client to speak directly with an IPv7 client. Because there is no such scheme, it is impossible. IPv4 was not made to be extendable so it is not.
You point to phone numbers. The phone numbers were made from the start to be extendable. It was never type 8 digits exactly. Never type less and never type any more - but that is exactly how IPv4 is. It is a fixed binary structure and there is no add an extra digit possible.
But as far as the administrative problem goes, somebody did think it would be smart if humans could type IPv4 style addresses for old stuff. So you can. I can ping 8.8.8.8 without first converting that into hex.
You are not making sense here. Of course the boxes on the same link need to share a subnet - just as they do with IPv4. So instead of 192.168.1.x/24 you would configure fd00::x/120.
Your router would be fd00::1. Your PC would be fd00::2. The printer fd00::3, the TV fd00::4 and so on. And yes that would work perfectly well. Today. You can even use DHCPv6 to make this work exactly like you are used to with DHCPv4.
The only difference here is that you need to remember "fd00::" instead of "192.168.1.".
But since you wanted it to look more like IPv4, we could point out that you can also name your network fd00::192.168.1.x. Why you would want to I don't know - but you can.
If your router is doing NAT64 it could export the legacy IPv4 network as fd00::a.b.c.d. That would make you feel home. It would not be a wrapper - you would be able to type ping6 fd00::8.8.8.8 from your computer, which happens to have the IP fd00::192.168.1.2.
All of that is possible today, although the usual CPE device does not ship with NAT64 and would not provide that configuration by default (because it is lame). But if you were to configure your own Linux router, you could make such a setup right now. There is no limitation in the IPv6 protocol stopping you from doing that. If it was smart, I am sure Linksys, Asus et al would do so.
You can. Or almost - it would need to be fd00::101.102.103.104/128 because::101.102.103.104 (the version with 96 zero bits in front) was deprecated some time ago.
But yes, typing "ip addr add fd00::101.102.103.104/128 dev eth0" on a Linux box will work.
You would need a nat device to translate that of course, but that is no different from having a computer with a 10.1.2.3 style address.
Nothing at all is stopping you from using fd00::192.168.1.0/120 instead of 192.168.1.0/24 on your internal network. Your router can then do the NAT translation needed for both IPv4 and IPv6 destinations.
Nobody would do that of course. There is no point in trying to force IPv4 think over the IPv6 network. By default your IPv6 network is plug and play and you need not worry about it at all.
You can embed IPv4 address in IPv6 addresses using IPv4 syntax.
You can use it to interact with the old IPv4 network like so:
baldur@ballerup1:~$ ping6 2001:778:0:ffff:64:0:8.8.8.8 PING 2001:778:0:ffff:64:0:8.8.8.8(2001:778:0:ffff:64:0:808:808) 56 data bytes 64 bytes from 2001:778:0:ffff:64:0:808:808: icmp_seq=1 ttl=41 time=73.2 ms 64 bytes from 2001:778:0:ffff:64:0:808:808: icmp_seq=2 ttl=41 time=73.0 ms ^C --- 2001:778:0:ffff:64:0:8.8.8.8 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 73.030/73.159/73.288/0.129 ms
That was a succesfull ping of 8.8.8.8 using an IPv6 only tool. The stuff I had to put in front of the address was the prefix of the nat64 gateway. Usually the user would not bother doing that manually. For example to ping slashdot I would first do:
slashdot.org has address 216.34.181.45 slashdot.org has IPv6 address 2001:778:0:ffff:64:0:d822:b52d slashdot.org mail is handled by 10 mx.sourceforge.net.
And ping 2001:778:0:ffff:64:0:d822:b52d which happens to the same as 2001:778:0:ffff:64:0:216.34.181.45.
Many ISPs will assign you a/48 prefix meaning you only need to remember 48 bits. The remaining bits is something you decide. You can decide it should all be zero. And all zero can be shortened to the string "::".
So your IPv6 address could be 2001:db8:beaf::
This happens to 15 characters. The typical IPv4 address is also 15 characters.
This is really easy: You will change the day someone tells you his end of the tunnel is only available on IPv6 and your grant depends on making this tunnel...
The fact that people forget is that the dual stack people have access to two internets. Single stack IPv4 people only have access to half of it. Some day you are going to want to peer with someone on the other net...
You got a/24. Good for you. There are only about 3 billion usable IPv4 addresses to be shared between 7 billion people on earth, and you got 256 of them. Yet you do not see a problem.
Maybe one day you will get a grant, that requires you to communicate with one of the people that got left out because of that attitude of yours. We can hope you will lose out on that grant, because you deserve it.
NAT puts state into the network where it does not belong. Everyone here seems to be focused on their own little home network. But have you thought about how easy it is to DoS a shared device, that tries to keep track of connections from dosens of users?
As any here should know, we are running out of IPv4 adresses. This means internet providers will deploy carrier NAT simply because there is no other choice. You will be sharing an IPv4 address with your neighbor. This is not the NAT you know today. It is a future where the kid next door provoked someone on an online game and got his IP address attacked by a denial of service attack. And you are just collateral damage because you happen to be sharing the IP address.
The ISPs are motivated to deploy IPv6 because this saves money. The carrier NAT devices are expensive and scale poorly. If you can move 50% of your traffic to IPv6 then you can also save 50% on the carrier NAT devices. Deploying IPv6 is practically free as most network equipment can do it already.
Carrier NAT devices are also a single point of failure in the carrier network. We do not like that.
There are solutions that tries to solve some of this, such as Address plus Port (RFC 6346). But this is not the NAT you know either. There will be no port forwarding from user specified ports, because you were assigned ports in some range and the port you want is in some other users range. Also all of this is much more complicated than simply deploying IPv6.
In short, in the future you will have crappy IPv4 and perfect IPv6. Why would you want to keep using the crappy IPv4?
Many here are assuming the world stands still. That there is no "we just ran out of IPv4". That we can just keep using IPv4 with no changes what so ever. But newsflash: this is not so, IPv4 is dying. Maybe it is better to do something about it now, than to wait until you really feel the pain?
Slashdot Mirror
Most speedtest servers are hosted on 1 gigabit/s which means you will probably never be able to get a clean 1 gigabit/s reading from those. That would require that you got the server all by yourself and that wont happen.
We are an ISP that sell gigabit. We host our own speedtest.net server on a 10 gigabit/s. It might be considered "cheating" as the user will only be measuring our internal network. But there is simply no other speedtest server nearby that is able to give consistent good readings. There are a couple that will give you ok readings ("almost 1 gig") but that depends on the time of the day and you might have to try several times.
And no, our transit connections are not congested. However ISPs that do not market themselves as selling 1 gig or more will have no reason to establish 10 gigabit/s at all interconnections. But that also means traffic to them will be limited by the interconnection.
Take a look at any IX member list and notice how many companies have only 1 gbps or slower ports. Our users will never get 1 gig to those guys if the traffic goes that route. Remember there will always be other traffic on the port as well.
However, if a user has traffic to multiple destinations he will usually be able to take full advantage. So it is good for families. You will never be slowed down by what others are doing in your household.
I work for an ISP. The way it works is, the 2 isp's have a free peering agreement... Every month or 3 they compare traffic and true up. You ate up 100gig more than we did? You party us X. And vice versa.
I own an ISP. This is not the way it works at all.
Peering policy is actually a rather complex topic. How it works depends on what kind of ISP you are and your size. Small ISPs want to peer no matter what. Large ISPs typically do not want to peer at all. The balanced peering requirement is a poor excuse to say no to peering.
As a small ISP we want to peer with all and everything. This is because any byte transmitted over a free peering is a byte that did not have to go via our paid transit circuit. It does not really matter in what direction that byte is going.
As a residential ISP the majority of our traffic is download. The transit cost is determined by the larger of upload and download. If we can get rid of some download, we will save good money. Netflix is offering to bring some of that download to us for free.
It is very asymmetric and it is a very good deal for both companies. It is a win-win.
So why do large ISPs not want to do this? Because they can get away with forcing everyone to pay to deliver traffic to them. It is no longer a win for them if they think they can get Netflix to be a paying customer. Nor if they already have free peering with the big transit providers, because then they are already getting the stream for free.
Why do mid sized ISPs not want to peer with small ISPs? If the mid sized ISP has a peering agreement with the transit provider of the small ISP, they are already getting the traffic for free. So there is no gain for them. On the other hand, the mid sized ISP might believe the smaller ISP could become a transit customer and you never peer with your customers or potential customers.
But instead of coming clear and tell the real reason, you will typically get the balanced peering requirement quote instead.
In truth balanced peering is not really possible nor desirable for a residential ISP. Only other residential ISP would have balance with us but there will be very little traffic. Just a little bit of bittorrent etc. As a residential ISP we need to peer with content providers, hosting companies and the like.
The only problem is that multicast is not actually deployed on the internet, so you can only use it locally. Sure some ISPs use it for their own TV streaming, but third parties are locked out from using it.
You assume the gears have no imperfections. You will find that it is not actually giving you the expected accuracy. Just a little bit of slack in the final gear could equal thousands of revolutions in the input gear.
You need torque to turn this thing. Due to the extreme reduction, the needed torque has little if any relation to what you put at the output. Instead it is just the internal friction of the plastic gears. Which means there is a point where further reduction does not make it any easier to turn.
You need strength in the part to use the output torque. Due to the extreme reduction, output torque is practically limited only to the point where the plastic gears break. There is a point where further reduction does not give you anything, because you are already past the point where the gears break.
Clearly this thing is way past both of those points.
You can not get infinite accuracy either. At some point the output shaft will stop moving smoothly compared to input, but instead move in a way determined by imperfections in the gears.
That has already been invented. It is called address plus port (RFC 6346 or A+P): https://tools.ietf.org/html/rf...
But it will only be used for "compatibility" - to communicate with IPv4 hosts that have not yet been upgraded to IPv6. If you think about it, there are no reason to deploy devices that can understand "quints" as that is just as big an upgrade to the IP stack as switching to IPv6.
Your home router will run the A+P function. It will share an IP address with other customers at your ISP. You will be assigned a port range with that shared IP address. The router will simply do NAT, so your devices on the home network do not need to know anything about this.
At some point you will find that it sucks not to be able to run ssh on port 22 and http on port 80. Therefore your helpful ISP has also provided you with IPv6, where no such limitations apply.
Also the trick only works with UDP and TCP, as other IP protocols do not use ports.
Replying to the guys that said it is illegal to sell: not only is it legal, but several of the internet registries put up their own marketplace for trading IP address space.
Here is a list of RIPE approved brokers: https://www.ripe.net/manage-ip...
That is not what should happen if you have it configured proper.
Say your prefix is 2001:db8:1::/48
Your LAN is 2001:db8:1:1::/64
Your WIFI is 2001:db8:1:2::/64
Your laptop has 2001:db8:1:1::10 on the LAN and 2001:db8:1:2::20 on the WIFI.
Now if you type ping6 2001:db8:1:1::42 it will automatically prefer the LAN interface and use the 2001:db8:1:1::10 IP address. It will not use the WIFI address unless you force it.
On the other hand if you ping6 2001:db8:1:2::42 it will select the WIFI interface and use 2001:db8:1:2::20 as source address.
If you ping something on the internet or if you ping 2001:db8:1:3::99 (assuming the laptop is not connected directly to that), it will first select an outgoing interface (either LAN or WIFI) and then pick the source address from that interface. Again unless you force it to do something different. These are the default address selection rules.
Yes zero global addresses on the link (GUA). You will of course have the link local address, which will be used for routing.
Typically your firewall is also the device that is handling the DHCP-PD with upstream and assigning /64s to your downstream routers or to different ports on the device. It will just work. It will not think that the traffic is spoofed. It will also do connection tracking and know exactly what is spoofed and what is not.
Devices will pick the correct IP from the outgoing interface. If your laptop has a Wifi connection, it will use the Wifi address when initiating connections that way. And the LAN address when sending out traffic on the wired network.
Applications can override that behavior but then you are dealing with misconfiguration or broken applications.
Trouble with devices connected to two subnets (links in IPv6 terms) at the same time are basically the same with IPv4 and IPv6.
Android does not support DHCPv6 at all. Proposing that they should implement IA_PD but not IA_NA is silly. Doing that might very well break PD on networks where there is a requirement that the next hob for the PD is known and stable. Such as ours...
What you can't do? You can't do tethering except on 3G/4G networks. Why you would want to? Dunno, but I notice that not every Android device is a phone. There could be use cases for that.
Also there are universities and large companies that simply wont let you do SLAAC. I have no experience running such networks, so I can not tell if they are right in doing that. I imagine they could have some of the same issues that we have in our ISP network (ND cache exhaustion etc). A simple defense could be to use a /120 or /112 with DHCPv6.
I do not know about APNIC, but RIPE accepts /48 assignments to end users. All ISPs in my country, which are doing IPv6 (which few of them are), are handing out /48 to users. So that is kind of the standard here.
Even the smallest ISP can get a /29 allocation from RIPE. That is a half a million of /48 assignments to give on to end users.
The problem with the idea of a global hierarchy routing is that the internet is not a hierarchy. BGP simply does not work like that. Solving that (if it needs solving) requires something more. One proposal is LISP.
Try using tethering while you have that Android on Wifi (tethering using bluetooth to a laptop). That wont work because that requires DHCPv6. Why would you want to? I don't know, but that is what is broken here.
It works while using cellular internet because they effectively have an alternative to DHCP-PD to assign a /64 prefix to the phone. They new LTE standard is switching to DHCP-PD so I wonder what Google will do then.
Except for cellular carriers, almost all ISPs are assigning multiple /64. Most are doing either /56 or /48.
The way to structure your internal network with three subnets is very simple. You will use three /64 out of the /56 or /48 that you got from your ISP.
There are many reasons that ISPs will not be assigning /64 or smaller. That is simply very hard on the ISP equipment. So have no fear, that will not become common.
Privacy extensions is an extension to SLAAC. All major operating systems come with privacy extensions enabled by default, which means they will do a dosen of adresses per device. If you enable SLAAC in the provider network and do not use DHCPv6-PD, most CPEs will bridge IPv6. That means the ISP switch/router has to track every single device inside your household multiplied by number of addresses used for privacy extensions.
But it is a problem even with no device actually using the address. If someone starts mapping your address space (eg. using nmap) the ISP router has to start NDP discovery on every single address that someone sends a ICMP ping to. There is no way the ISP router can know that there is no device with that address. The only defense is to limit the number of active cache entries per customer, but then you just made it very simple to DoS the customer with trivial amount of ICMP traffic.
For this reason the sane way to implement IPv6 as to do DHCPv6-PD and assign either 0 or 1 IPv6 address on the link interface. Zero is possible because IPv6 can use link local addresses for routing, but it will screw up your traceroute and arguably it prevents the CPE from sending back mandatory ICMP packets such as MTU changes.
I work for a (smallish) ISP so let me tell you why you will simply not get any IPv6 service without DHCPv6 on our network.
It has nothing at all to do with being IPv4 old-timers. That is just you not understanding the complexity of the world out there. Our network was build from the start with the idea that IPv6 is the future.
We use DHCPv6 to provide every user with his own /48 prefix. Yes you said that DHCPv6 is a great solution for prefixes. But we also use it to deliver a /128 to go with that prefix. We need this to have a stable and predictable address that we can use as next hob for your shiny new prefix.
We had this very same debate on the NANOG mailing list. Some people there asked why does your routers not sniff the DHCPv6 packet and add the route dynamically? Two reasons. One, that is not in any standard, so our vendor did not implement it. Two, it does not work if you have router redundancy (how would the backup router know the route?).
There are more reasons an ISP would not want to use SLAAC. It exposes 2**64 addresses to the ISP network access routers. This can harm the network in many different ways and you simply do not want your ND caches to be full of that crap. You want to use as few slots in the shared ND cache per user. Therefore you are going to disable SLAAC on the customer edge and use some other mechanism. One guy suggested not using GUA on the customer links and only use link local addressing here. We choose to use /128 DHCPv6 assigned addresses. In either case, GUA-SLAAC is a fail in the provider network.
SLAAC is great inside the household of our customers. But we leave that decision to the customer and his choice of CPE-router.
The problem with Android is that it should really be able to act like a CPE for tethering purposes. Therefore is should be able to accept our CPE configuration. Android should also be able to ask for a prefix to be sub-delegated from the house CPE and it should accept that this might come with extra addresses that will be used for routing or for other purposes.
Where to start?
1) IPv4 vs IPv6 has nothing to do with ASN. If you do have an ASN you will be using the same ASN for both protocols. With 32 bit ASN now in wide use, there is nothing limiting you from applying for one. Get your own /48 prefix with it.
2) IPv6 has NAT.
3) Multihoming is perfectly possible using IPv6. There is no rule telling you not to do it exactly like you always did with IPv4.
4) There is no rule that say you can not split a /64. You can split it down to /128 if you want. The only thing that breaks is SLAAC but you can still use DHCPv6 or static/manual configuration.
5) All major ISPs are giving out /56 or more address space, so you have no need to split a /64.
6) All major operating systems use privacy extension enabled by default, so you MAC will not be exposed when you surf the net. Your device will be no more tracked than with IPv4-NAT since it changes address all the time.
All IPv6 gives you are options. There are now more ways to do the above things. But in no way did you lose the ability to keep doing things like yesterday.
::ffff:a.b.c.d is what is used inside programs that want to use just one socket type (IPv6) to handle both protocols. I believe your OS might very well refuse to configure that on an interface.
I admit to abuse fd00::/8 but not any more than what the IPv4 think brings you anyway. Using the very first network of fd00::/8 will bring you the pain of colliding with everyone else that did exactly the same, but you will not likely collide with someone who cared enough to generate a global unique ULA prefix. This is 100% equal to having the majority of home networks on the same /24 network (192.168.1.x). You lose the advantage that IPv6 was supposed to get you, but some people here seems to be dead set to lose all that if they can, just because they don't like hex.
In another livetime I made a fd00:: prefix generator: http://bitace.com/ipv6calc/
Oh I see. You did not get the fact that when I type ping6 2001:778:0:ffff:64:0:8.8.8.8 on my IPv6 only computer, then I am in fact pinging 8.8.8.8 which happens to be a real IPv4 only server out there. You said why didn't they embed the old number plan in the new one - and they did. Multiple times actually.
If I have a NAT64 device on my local network, then my IPv6 only machine can in fact communicate with IPv4 only devices. The packets will go through the NAT64 device, because there simply is no other way - and that is a technical problem, not administrative.
We have seen a zillion proposals for alternative "IPv7" plans including yours. None have explained how that scheme would allow an old IPv4 client to speak directly with an IPv7 client. Because there is no such scheme, it is impossible. IPv4 was not made to be extendable so it is not.
You point to phone numbers. The phone numbers were made from the start to be extendable. It was never type 8 digits exactly. Never type less and never type any more - but that is exactly how IPv4 is. It is a fixed binary structure and there is no add an extra digit possible.
But as far as the administrative problem goes, somebody did think it would be smart if humans could type IPv4 style addresses for old stuff. So you can. I can ping 8.8.8.8 without first converting that into hex.
You are not making sense here. Of course the boxes on the same link need to share a subnet - just as they do with IPv4. So instead of 192.168.1.x/24 you would configure fd00::x/120.
Your router would be fd00::1. Your PC would be fd00::2. The printer fd00::3, the TV fd00::4 and so on. And yes that would work perfectly well. Today. You can even use DHCPv6 to make this work exactly like you are used to with DHCPv4.
The only difference here is that you need to remember "fd00::" instead of "192.168.1.".
But since you wanted it to look more like IPv4, we could point out that you can also name your network fd00::192.168.1.x. Why you would want to I don't know - but you can.
If your router is doing NAT64 it could export the legacy IPv4 network as fd00::a.b.c.d. That would make you feel home. It would not be a wrapper - you would be able to type ping6 fd00::8.8.8.8 from your computer, which happens to have the IP fd00::192.168.1.2.
All of that is possible today, although the usual CPE device does not ship with NAT64 and would not provide that configuration by default (because it is lame). But if you were to configure your own Linux router, you could make such a setup right now. There is no limitation in the IPv6 protocol stopping you from doing that. If it was smart, I am sure Linksys, Asus et al would do so.
You can. Or almost - it would need to be fd00::101.102.103.104/128 because ::101.102.103.104 (the version with 96 zero bits in front) was deprecated some time ago.
But yes, typing "ip addr add fd00::101.102.103.104/128 dev eth0" on a Linux box will work.
You would need a nat device to translate that of course, but that is no different from having a computer with a 10.1.2.3 style address.
Nothing at all is stopping you from using fd00::192.168.1.0/120 instead of 192.168.1.0/24 on your internal network. Your router can then do the NAT translation needed for both IPv4 and IPv6 destinations.
Nobody would do that of course. There is no point in trying to force IPv4 think over the IPv6 network. By default your IPv6 network is plug and play and you need not worry about it at all.
They already did that:
baldur@ballerup1:~$ ping6 ::101.102.103.104 ::101.102.103.104(::101.102.103.104) 56 data bytes ::101.102.103.104 ping statistics ---
PING
^C
---
5 packets transmitted, 0 received, 100% packet loss, time 4030ms
You can embed IPv4 address in IPv6 addresses using IPv4 syntax.
You can use it to interact with the old IPv4 network like so:
baldur@ballerup1:~$ ping6 2001:778:0:ffff:64:0:8.8.8.8
PING 2001:778:0:ffff:64:0:8.8.8.8(2001:778:0:ffff:64:0:808:808) 56 data bytes
64 bytes from 2001:778:0:ffff:64:0:808:808: icmp_seq=1 ttl=41 time=73.2 ms
64 bytes from 2001:778:0:ffff:64:0:808:808: icmp_seq=2 ttl=41 time=73.0 ms
^C
--- 2001:778:0:ffff:64:0:8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 73.030/73.159/73.288/0.129 ms
That was a succesfull ping of 8.8.8.8 using an IPv6 only tool. The stuff I had to put in front of the address was the prefix of the nat64 gateway. Usually the user would not bother doing that manually. For example to ping slashdot I would first do:
baldur@ballerup1:~$ host slashdot.org 2001:778::37
Using domain server:
Name: 2001:778::37
Address: 2001:778::37#53
Aliases:
slashdot.org has address 216.34.181.45
slashdot.org has IPv6 address 2001:778:0:ffff:64:0:d822:b52d
slashdot.org mail is handled by 10 mx.sourceforge.net.
And ping 2001:778:0:ffff:64:0:d822:b52d which happens to the same as 2001:778:0:ffff:64:0:216.34.181.45.
Many ISPs will assign you a /48 prefix meaning you only need to remember 48 bits. The remaining bits is something you decide. You can decide it should all be zero. And all zero can be shortened to the string "::".
So your IPv6 address could be 2001:db8:beaf::
This happens to 15 characters. The typical IPv4 address is also 15 characters.
This is really easy: You will change the day someone tells you his end of the tunnel is only available on IPv6 and your grant depends on making this tunnel...
The fact that people forget is that the dual stack people have access to two internets. Single stack IPv4 people only have access to half of it. Some day you are going to want to peer with someone on the other net...
You got a /24. Good for you. There are only about 3 billion usable IPv4 addresses to be shared between 7 billion people on earth, and you got 256 of them. Yet you do not see a problem.
Maybe one day you will get a grant, that requires you to communicate with one of the people that got left out because of that attitude of yours. We can hope you will lose out on that grant, because you deserve it.
NAT puts state into the network where it does not belong. Everyone here seems to be focused on their own little home network. But have you thought about how easy it is to DoS a shared device, that tries to keep track of connections from dosens of users?
As any here should know, we are running out of IPv4 adresses. This means internet providers will deploy carrier NAT simply because there is no other choice. You will be sharing an IPv4 address with your neighbor. This is not the NAT you know today. It is a future where the kid next door provoked someone on an online game and got his IP address attacked by a denial of service attack. And you are just collateral damage because you happen to be sharing the IP address.
The ISPs are motivated to deploy IPv6 because this saves money. The carrier NAT devices are expensive and scale poorly. If you can move 50% of your traffic to IPv6 then you can also save 50% on the carrier NAT devices. Deploying IPv6 is practically free as most network equipment can do it already.
Carrier NAT devices are also a single point of failure in the carrier network. We do not like that.
There are solutions that tries to solve some of this, such as Address plus Port (RFC 6346). But this is not the NAT you know either. There will be no port forwarding from user specified ports, because you were assigned ports in some range and the port you want is in some other users range. Also all of this is much more complicated than simply deploying IPv6.
In short, in the future you will have crappy IPv4 and perfect IPv6. Why would you want to keep using the crappy IPv4?
Many here are assuming the world stands still. That there is no "we just ran out of IPv4". That we can just keep using IPv4 with no changes what so ever. But newsflash: this is not so, IPv4 is dying. Maybe it is better to do something about it now, than to wait until you really feel the pain?