...and I meant to add a link to bug 659285 there, but I dropped a quote and the entire <a> tag got stripped out, and I somehow missed it in the preview. Sigh.
But if dual-stack is the expected norm, that kinda makes the "push to move everyone to v6 to solve the network address issue" a bit of a fail.
Not really: the v4 side will end up behind piles of NAT and generally suck, but that doesn't matter anywhere near as much if it's just for backwards compatibility rather than being all you've got.
I thought one of the goals of the v6 addressing space, at least initially, was that there would be a "v4 compatibility" built into the V6 addressing space, at least for some sense of local addresses -- so that you could talk to a v4 device that was on the same local network.
And it does have that. The main backwards compatibility method is to just use the v4 stack as-is. It's the easiest possible way to do it (you don't even have to do anything: your existing network does the job already) and it's guaranteed to be the most compatible (because you're already using it). It's also the only way to do it on a LAN, where you're talking directly to the other machine without a router in the way to translate.
You mention that there is a NAT64, and I can make some guesses as to how it operates, at least if the V6 machine is initiating the connection. You also mention that there are multiple ways to make this work; so why not have a single standard that works?
Roughly the same as NAT44 does, except with v6 addresses on the local side. You're right, it'll be outbound only, unless you configure a "port forward" (more of an IP forward).
("Roughly" because there is the issue of getting client programs to connect to 64:ff9b::203.0.113.1 instead of 203.0.113.1. Normally you do this by inventing fake DNS responses -- this is the "a few extra problems of its own" part.)
There are multiple transition methods because they target different scenarios. 6to4 allows a v6-capable device with only a (public) v4 address to talk to v6 hosts (and it gives you a/48, so you can do v6 for an entire network behind you). Teredo is similar, except it works for clients behind NAT, at the cost of only giving you a single address rather than a/48. NAT64 lets v6 clients talk to v4 servers (but not the other way around), even ones that aren't v6-capable. They're all useful in different cases.
So first, a question: Can v4 devices talk to v6 devices?
Not without one of the transition mechanisms (NAT64, 6to4, Teredo). There's no space for a v6 address in the v4 dest header field.
If I have an older device, such as a printer, that can only talk v4, then in order to talk to it, I need a v4 address. Given that there will be some devices out there that can only talk v4, then there needs to be some way for v4 machines to talk to v6 machines.
Generally this is done by not removing the v4 address from your v6-capable machines. The v6-capable machines are inevitably also capable of talking v4, and they're hooked up to the same ethernet segment as your v4-only devices, so they'll also be getting v4 addresses. They just use those when they want to talk to a v4-only machine.
So, is it possible for a v6 host to initiate a connection to a v4 device by using some magic prefix to indicate "the bottom 4 bytes contain a v4 address, and you, router, are supposed to pretend that you are talking v4 using that"?
This is roughly what NAT64 does. (I will note however that NAT64 has all of the problems that NAT44 does, plus a few extra of its own.)
If so, the next question is: when the v4 device wants to respond, what does it put into it's destination IP field to get back to the v6 device?
It uses whatever was in the source field, which will be the v4 address of the NAT64 gateway. The gateway is responsible for maintaining state for each connection, so it knows what the original v6 src address was.
If I cannot talk to a v4-only device from a v6-only host, then I need to have a mixed 4/6 machine.
Yep. Dual stack is the expected (and easiest) migration method.
The need for routers to be able to translate between v4 and v6 to support old hardware leads into the question about V8.
This isn't really necessary. As I say: dual stack is the expected way to deal with old hardware.
This already happens automatically. With privacy addresses enabled (which is the default on pretty much everything), your system will automatically generate itself a new random address every 24 hours. The GP's worry about being able to trivially identify which device was using each IP will not actually happen (unless you've specifically gone and disabled privacy addresses...).
An IP is not a "digital fingerprint". Knowing the v6 address won't let you figure out who was using it at the time, or even what device it was assigned to.
With privacy extensions (which are on by default in basically everything), knowing the v6 address is about as useful as knowing the v4 address. Removing NAT from your network doesn't affect governments or media cartels -- but meanwhile it makes your own life much easier, so you're being dumb if you insist on using it when it's not necessary.
Something like the iBot, a wheelchair that could pop up onto (and balance on) two wheels to bring you to standing eye height? Developed by the guy who would later make the Segway?
(Unfortunately, insurance companies declared it "not medically necessary" and refused to pay for it, so nobody has ever heard of it and it ended up failing.)
I would've initially accepted steps towards a v6 deployment, e.g. if you've just got your v6 allocation and you're turning up BGP next week? Fine, but when you come back for more v4 in 3 months then you'd best have made some more progress or you aren't getting any.
Instead we got... a discount on your v6 allocations if you already have v4 allocations. Which has since been phased out. Woo.
Look at page 2 of the RFC you linked. It explicitly says that class C networks are/24s that start with 0b110, i.e. are in 192.0.0.0/3, and class A networks are/8s that start with 0b0 ("in 0.0.0.0/1").
Hence "*twitch*". If you want to talk about/24s, just call them/24s.
Well, I read it, but... the class A space and the class C space don't overlap. You can't have class Cs from 10/8, because the class C space is 192.0.0.0/3.
The fact that there are still providers that haven't finished (or even started) their deployments is exactly why extra time wouldn't be helpful. They've had years and years to deploy v6; the only reason for not being done by now is that they've been procrastinating.
We've already bought these people an extra 10-20 years with pervasive NAT and over-aggressive address conservation. Buying them an extra 2 years would just lead to another 2 years of procrastination. Enough is enough. It's time they got a move on, and if they have to suffer through some (more) pain to get there then they only have themselves to blame.
I'd've loved to see ARIN put a "you can only get v4 space if you show us that you're doing a serious v6 deployment too" policy on their last/8. Bit late for that now though.
None of this will fix anything, because the v4 space just plain isn't big enough. It doesn't matter how you slice and dice it: there ain't enough of it.
You might be able to buy some extra time this way, but we've had more than enough time already. "More time" isn't what we need at this point.
and everybody involved in the conversation understands that the IP is 2001:db8:42::53, since the company's allocation is 2001:db8:42::/48. Heck, this is less bits to remember than 203.0.113.42 + 10.10.10.1, so if anything you're describing a problem with v4, not v6.
Everything larger than a/23 is getting denied now. Once they allocate the 55 remaining/23s (probably in a week or two), everything larger than a/24 will be denied. When they allocate the last 430 of those (in... 1-2 months?) then they'll be denying everything.
The real picture is that IP addresses are allocated hierarchically and there are multiple entities at all levels except the root, all of which run out separately.
IANA (the root of the tree, the people who allocate addresses to the regional registries) ran out of/8s in Feb 2011. The regional registries (there are five of them; these are the people that allocate addresses to ISP) have their allocated pools of/8s which ran out at different times: APNIC ran out in Apr 2011 (that's the story you linked), RIPE in 2012, LACNIC in 2014 and ARIN just now. (AFRINIC still has a few years to go, although they won't if everybody tries to get their addresses from there.)
Then there are the ISPs, who allocate addresses to their customers. ISPs will tell you that "we have plenty of addresses left" -- except the ones who don't -- but at some point all ISPs (or perhaps more importantly, your ISP) are going to move into the "don't" category.
And finally, ISP customers (i.e. you) allocate addresses to networks. Except you've probably never experienced this, because we've been short on v4 addresses for long enough that many ISPs don't (can't) give you enough IPs for your networks, and haven't for years and years. You probably grew up with this and consider it normal; it's not.
I don't know when you're going to go from "we seem to be trucking on just fine" to realizing that we have a problem -- I'd say we already do, since lots of people waste lots of time and money due to NAT, but perhaps for you it'll take your ISP giving you an RFC 1918 address on your upstream before you realize. Or maybe you have infinite time and money and don't mind the headaches caused by many layers of NAT and all the workarounds needed to deal with them, and you don't mind paying programmers to write workarounds into software, and you don't care about all the things we could've had if the internet had been up to providing them. But hopefully I've shed some light on the highly-complicated reality of "guy A allocates to guy B who allocates to guy C".
Which is what... two years worth of IPs? That's not going to solve anything. No amount of reallocating or reclaiming or reshuffling is going to save v4, because v4 is just plain too small.
We might be able to buy some extra time that way, but we've had plenty of time to handle things already. More time isn't going to help at this point.
The addresses aren't there. v4 is just plain too small. Freeing up a few/8s won't change that: there are more than 2^32 devices connected to the internet, so no matter how many blocks you reclaim, it's still not going to be big enough.
Slashdot Mirror
Which is awesome, if Mozilla add the standardized interface to do whatever it is you need to do.
Which, for many things, they won't. Otherwise you wouldn't be writing the damn extension in the first place.
...and I meant to add a link to bug 659285 there, but I dropped a quote and the entire <a> tag got stripped out, and I somehow missed it in the preview. Sigh.
It works for .play() too, as of Fx41.
Hold Alt (in Firefox, at least). Although that is certainly more of a pain than just clicking on a link.
You get bonus points if you actually give the right link too.
But if dual-stack is the expected norm, that kinda makes the "push to move everyone to v6 to solve the network address issue" a bit of a fail.
Not really: the v4 side will end up behind piles of NAT and generally suck, but that doesn't matter anywhere near as much if it's just for backwards compatibility rather than being all you've got.
I thought one of the goals of the v6 addressing space, at least initially, was that there would be a "v4 compatibility" built into the V6 addressing space, at least for some sense of local addresses -- so that you could talk to a v4 device that was on the same local network.
And it does have that. The main backwards compatibility method is to just use the v4 stack as-is. It's the easiest possible way to do it (you don't even have to do anything: your existing network does the job already) and it's guaranteed to be the most compatible (because you're already using it). It's also the only way to do it on a LAN, where you're talking directly to the other machine without a router in the way to translate.
You mention that there is a NAT64, and I can make some guesses as to how it operates, at least if the V6 machine is initiating the connection. You also mention that there are multiple ways to make this work; so why not have a single standard that works?
Roughly the same as NAT44 does, except with v6 addresses on the local side. You're right, it'll be outbound only, unless you configure a "port forward" (more of an IP forward).
("Roughly" because there is the issue of getting client programs to connect to 64:ff9b::203.0.113.1 instead of 203.0.113.1. Normally you do this by inventing fake DNS responses -- this is the "a few extra problems of its own" part.)
There are multiple transition methods because they target different scenarios. 6to4 allows a v6-capable device with only a (public) v4 address to talk to v6 hosts (and it gives you a /48, so you can do v6 for an entire network behind you). Teredo is similar, except it works for clients behind NAT, at the cost of only giving you a single address rather than a /48. NAT64 lets v6 clients talk to v4 servers (but not the other way around), even ones that aren't v6-capable. They're all useful in different cases.
So first, a question: Can v4 devices talk to v6 devices?
Not without one of the transition mechanisms (NAT64, 6to4, Teredo). There's no space for a v6 address in the v4 dest header field.
If I have an older device, such as a printer, that can only talk v4, then in order to talk to it, I need a v4 address.
Given that there will be some devices out there that can only talk v4, then there needs to be some way for v4 machines to talk to v6 machines.
Generally this is done by not removing the v4 address from your v6-capable machines. The v6-capable machines are inevitably also capable of talking v4, and they're hooked up to the same ethernet segment as your v4-only devices, so they'll also be getting v4 addresses. They just use those when they want to talk to a v4-only machine.
So, is it possible for a v6 host to initiate a connection to a v4 device by using some magic prefix to indicate "the bottom 4 bytes contain a v4 address, and you, router, are supposed to pretend that you are talking v4 using that"?
This is roughly what NAT64 does. (I will note however that NAT64 has all of the problems that NAT44 does, plus a few extra of its own.)
If so, the next question is: when the v4 device wants to respond, what does it put into it's destination IP field to get back to the v6 device?
It uses whatever was in the source field, which will be the v4 address of the NAT64 gateway. The gateway is responsible for maintaining state for each connection, so it knows what the original v6 src address was.
If I cannot talk to a v4-only device from a v6-only host, then I need to have a mixed 4/6 machine.
Yep. Dual stack is the expected (and easiest) migration method.
The need for routers to be able to translate between v4 and v6 to support old hardware leads into the question about V8.
This isn't really necessary. As I say: dual stack is the expected way to deal with old hardware.
This already happens automatically. With privacy addresses enabled (which is the default on pretty much everything), your system will automatically generate itself a new random address every 24 hours. The GP's worry about being able to trivially identify which device was using each IP will not actually happen (unless you've specifically gone and disabled privacy addresses...).
Are you sure about that? This presentation says they're allocating a /56.
An IP is not a "digital fingerprint". Knowing the v6 address won't let you figure out who was using it at the time, or even what device it was assigned to.
With privacy extensions (which are on by default in basically everything), knowing the v6 address is about as useful as knowing the v4 address. Removing NAT from your network doesn't affect governments or media cartels -- but meanwhile it makes your own life much easier, so you're being dumb if you insist on using it when it's not necessary.
Yeah, let's get that block back. That should buy v4 about two hours or so. That'll totally save us.
Something like the iBot, a wheelchair that could pop up onto (and balance on) two wheels to bring you to standing eye height? Developed by the guy who would later make the Segway?
(Unfortunately, insurance companies declared it "not medically necessary" and refused to pay for it, so nobody has ever heard of it and it ended up failing.)
I would've initially accepted steps towards a v6 deployment, e.g. if you've just got your v6 allocation and you're turning up BGP next week? Fine, but when you come back for more v4 in 3 months then you'd best have made some more progress or you aren't getting any.
Instead we got... a discount on your v6 allocations if you already have v4 allocations. Which has since been phased out. Woo.
Look at page 2 of the RFC you linked. It explicitly says that class C networks are /24s that start with 0b110, i.e. are in 192.0.0.0/3, and class A networks are /8s that start with 0b0 ("in 0.0.0.0/1").
Hence "*twitch*". If you want to talk about /24s, just call them /24s.
Well, I read it, but... the class A space and the class C space don't overlap. You can't have class Cs from 10/8, because the class C space is 192.0.0.0/3.
The fact that there are still providers that haven't finished (or even started) their deployments is exactly why extra time wouldn't be helpful. They've had years and years to deploy v6; the only reason for not being done by now is that they've been procrastinating.
We've already bought these people an extra 10-20 years with pervasive NAT and over-aggressive address conservation. Buying them an extra 2 years would just lead to another 2 years of procrastination. Enough is enough. It's time they got a move on, and if they have to suffer through some (more) pain to get there then they only have themselves to blame.
I'd've loved to see ARIN put a "you can only get v4 space if you show us that you're doing a serious v6 deployment too" policy on their last /8. Bit late for that now though.
None of this will fix anything, because the v4 space just plain isn't big enough. It doesn't matter how you slice and dice it: there ain't enough of it.
You might be able to buy some extra time this way, but we've had more than enough time already. "More time" isn't what we need at this point.
*twitch*
"class C"?? 10/8 is class A. It's almost as far away as you can get from the class C ranges!
Spammers are already using it.
I only had to look at 3 emails in my spam folder before I found one that was delivered over v6.
Not really:
"What's the DNS IP?"
"It's at 53"
"Got it!"
and everybody involved in the conversation understands that the IP is 2001:db8:42::53, since the company's allocation is 2001:db8:42::/48. Heck, this is less bits to remember than 203.0.113.42 + 10.10.10.1, so if anything you're describing a problem with v4, not v6.
Everything larger than a /23 is getting denied now. Once they allocate the 55 remaining /23s (probably in a week or two), everything larger than a /24 will be denied. When they allocate the last 430 of those (in... 1-2 months?) then they'll be denying everything.
For reasons which are wrong or don't make sense.
APNIC ran out in Apr 2011 (that's the story you linked),
Sorry, my bad. You linked the IANA runout, APNIC is here. (For completeness, RIPE is here and LACNIC is here.)
The real picture is that IP addresses are allocated hierarchically and there are multiple entities at all levels except the root, all of which run out separately.
IANA (the root of the tree, the people who allocate addresses to the regional registries) ran out of /8s in Feb 2011. The regional registries (there are five of them; these are the people that allocate addresses to ISP) have their allocated pools of /8s which ran out at different times: APNIC ran out in Apr 2011 (that's the story you linked), RIPE in 2012, LACNIC in 2014 and ARIN just now. (AFRINIC still has a few years to go, although they won't if everybody tries to get their addresses from there.)
Then there are the ISPs, who allocate addresses to their customers. ISPs will tell you that "we have plenty of addresses left" -- except the ones who don't -- but at some point all ISPs (or perhaps more importantly, your ISP) are going to move into the "don't" category.
And finally, ISP customers (i.e. you) allocate addresses to networks. Except you've probably never experienced this, because we've been short on v4 addresses for long enough that many ISPs don't (can't) give you enough IPs for your networks, and haven't for years and years. You probably grew up with this and consider it normal; it's not.
I don't know when you're going to go from "we seem to be trucking on just fine" to realizing that we have a problem -- I'd say we already do, since lots of people waste lots of time and money due to NAT, but perhaps for you it'll take your ISP giving you an RFC 1918 address on your upstream before you realize. Or maybe you have infinite time and money and don't mind the headaches caused by many layers of NAT and all the workarounds needed to deal with them, and you don't mind paying programmers to write workarounds into software, and you don't care about all the things we could've had if the internet had been up to providing them. But hopefully I've shed some light on the highly-complicated reality of "guy A allocates to guy B who allocates to guy C".
Which is what... two years worth of IPs? That's not going to solve anything. No amount of reallocating or reclaiming or reshuffling is going to save v4, because v4 is just plain too small.
We might be able to buy some extra time that way, but we've had plenty of time to handle things already. More time isn't going to help at this point.
The addresses aren't there. v4 is just plain too small. Freeing up a few /8s won't change that: there are more than 2^32 devices connected to the internet, so no matter how many blocks you reclaim, it's still not going to be big enough.