It's trivially easy to exhaustively scan the entire v4 internet space. Trying to do the same to the v6 space isn't going to work. There are ways to pare down the search space somewhat, but ultimately Shodan is going to be listing every single exposed v4 service but not very many of the v6 ones.
It doesn't even do that much. The only thing this feature does is, if an MITM is detected, to change the text on the "unrecognized issuer" error page. You won't see the MITM detected error except in situations where you would otherwise be getting an unrecognized issuer error. You're just getting a slightly nicer error message.
'Trusted' MITM already requires you to install the MITM cert manually to avoid getting unrecognized issuer errors on every page load.
That does not appear to be how it works. From reading the patch: if it fails to connect to the Firefox update service then it records the issuer of the cert that the update service presented. Then, if a future TLS connection fails with an unrecognized issuer and the unrecognized issuer matches the issuer that was recorded from the update service, then it displays the MITM error instead of the unrecognized issuer error.
This is pretty obviously not the case, because Firefox still supports bootstrapped extensions (which is the technology used to do old extensions and UI customization). They've been limited to extensions signed with a special Mozilla key, because obviously WEs are perfect and everybody should use them except for Mozilla themselves who get special treatment, but they're still supported.
If Firefox can get its current performance while still supporting bootstrapped extensions, then clearly it's possible to get its current performance while still supporting bootstrapped extensions. The speed improvements come from things that can be done at the same time as supporting bootstrapped extensions.
The reason projects like Pale Moon don't get the same improvements is because the patches to do so are huge and integrating them without also integrating the changes that screw up UI appearance is an incredibly complicated job that takes more manpower than they have available.
No, we wouldn't have plenty of space. A v4/8 is only 16 million addresses, and before RIR runout back in 2011 we were going through those/8s in less than a month each. Demand has only gone up since then, and it's reasonable to believe that a v4/8 would be something around a two-week supply of IPs at today's usage rates. There are only maybe 20 or so/8s held by companies, so that would be less than a year worth of addresses. The v4 space is simply too small, no matter how you slice and dice it.
And don't worry; we did learn our lessons. You don't see anybody giving out/8s in v6, do you? Nobody is getting that large a fraction of the v6 space.
(Expanding TCP wouldn't be any help either. Our problem isn't TCP port numbers, which we have more than enough of; it's IP addresses.)
Based on this article, I can believe they shipped flawed CPUs without knowing about the flaws. However, if so, it's because they deliberately stopped investing as much effort into finding the flaws in the first place.
And they certainly knew what they were doing when they scaled back their validation.
What I meant was, you didn't seem to have followed it through to the conclusion. It's easy to say "obviously you arrange things so that", but when you start trying to work out what the wire protocol will look like in order to do that, it seems to me that it's going to look very much like v6 already does. (If not, feel free to explain how you'd do it.)
Ah, so you did have the start of an idea... but I'm not really seeing how it differs from dual stack. It looks like you're suggesting to have an unmodified v4 stack to handle talking to v4 hosts, plus an "extended v4" stack to handle talking to v6 hosts. Or perhaps you're suggesting combining them into the same piece of code, but even if you did that, so long as you're using two different addresses and are talking two different wire protocols then it's still effectively dual stack. Calling it something different doesn't help.
How does your suggestion let v6 hosts talk to v4 hosts? "By using v4", okay. How does it let v4 hosts talk to v6 hosts? I don't see a way of making that work that isn't "by using v6". And how do routers handle routing it? Again it seems to require that the router do v6. If there's a difference in the backwards compatibility afforded by this vs by dual stack, I'm having trouble seeing it. What's the difference that I'm missing?
I'm willing to try, and I have tried, but I very quickly hit the pidginhole principle and I can't think of any way around that other than the ways that we are already using. I've gone over other people's suggestions too, but they generally either don't work or they suffer from the same issues that v6 already suffers from.
And you're right, I don't know that you haven't come up with anything. I just don't get why you'd keep it to yourself if you had.
So you at least agree that it exists, and neither of us have been able to come up with any better ways of doing it so it seems likely that it's about as good as it can get. I guess you can argue it's not good enough, but if it can't be made any better then you can't really criticize v6 for not making it any better. (Instead, criticize v4 for not allowing any better mechanism.)
I'd say that dual stack never was necessary. It has always been possible to remove v4 from your network; v6 doesn't force you to keep it. The fact that I'm running a single-stack v6 desktop right now, with access to v4-only sites, demonstrates that. It's just that it's the only real way to keep existing v4-only software and devices working, and if that's something that you care about then what better choice do you have? If you do in fact have a better option then I'm all ears, but I'm not sure what you could possibly do that would work with existing v4-only stuff.
464XLAT support in OSs would've been, and would still be, really damn useful for dealing with v4-only software, but that doesn't help v4-only devices.
It sounds like you've done a 180 and now agree that v6's backwards compatibility does in fact exist and works well enough, even though it doesn't and can't work perfectly (like I pointed out at the beginning and have been pointing out the whole time). That's good to hear, even though your attitude sure doesn't suggest you've realized that you've done it.
Incidentally, I posted this from a machine that only has v6. Slashdot works fine from this machine, and in fact I've yet to find a website that doesn't work from it. How is that an island, any more so than NAT44 already is?
It sounds like "natural oligopoly" would indeed be more to your taste then.
You're right that regulatory capture also tends to raise the barrier to entry, and that's obviously a problem, but let's not pretend that it's the only barrier to entry involved in doing last-mile telecommunications. You can fix the regulatory capture issue, but burying thousands of miles of fibre is still inherently going to be expensive -- that's the "natural" part (as opposed to the regulatory capture, which obviously isn't natural).
To respond in kind: if it's not a natural monopoly, how do you not have dozens of choices? I have a choice of something like 50 ISPs.
Perhaps calling it a "naturally monopolistic market", or a "natural oligopoly" would be more to your taste. The point is that there's a high barrier to entry due to the costs of physically sticking cables in the ground, and getting rid of anti-competition regulation doesn't make those costs go away.
I already mentioned, multiple times, tunnelling and NAT as viable backwards compatibility options that are already available in v6, but if you remember, I asked you if those counted and your response was "In the ways that count, ipv6 is incompatible" and you called me stupid for mentioning them as a way to do backwards compatibility.
That's why I've been asking you to tell us your idea for making it compatible in a way that you consider as counting -- because as far as I can tell it's not possible to do, and I don't think it's fair in the slightest to blame v6 for not doing something that's not possible in the first place. Or are you now admitting that 6to4 and NAT64 actually do count as backwards compatibility?
Embedding v4 into the v6 space is easy enough, but how does that get you backwards compatibility? We already have::ffff:<v4 addr> which does the embedding, but how do you enable two-way communication? If you could somehow also embed v6 into the v4 space then it'd be pretty easy, but there's not enough space in v4 to do that (if there was we wouldn't need v6 in the first place).
This post is either the 4th or the 5th time that I've asked you to describe a way of doing backwards compatibility in a way that would satisfy you. I think it's about time you either did so, or admitted that v6 is already doing the best backwards compatibility that it can given the constraints that it's working under.
The logic is pretty well-supported: v4 is limited to 32 bit addresses, so there's no way for it to specify which v6 host it wants to communicate with. That, right there, kills your ability to do perfect backwards compatibility. There are some ways around that limitation, but v6 implements those ways and you already dismissed them as not counting further up.
If you think it's possible to do full backwards compatibility in a way that you'd accept, then you could easily convince us by just describing a way to do it (a valid way, one that works and doesn't have the limitations of the existing ways). The fact that you can't -- and then call us incompetent, as if it was our fault that you can't answer -- just makes it more and more obvious that you don't actually have a way to do it.
Both stateful firewalling and NAT require state tracking, so they're often implemented in the same piece of software or hardware. Nevertheless, the firewalling and the NAT parts are logically separate components. The NAT part is responsible for rewriting addresses, and the firewall part is responsible for deciding which packets to drop.
Perhaps you could spend less time insulting me (and Vint Cerf; what on earth did that man do to you?) and more time answering the question.
Dumping 80 pages of whitepaper on me isn't very reasonable, but okay, I went through it. The interesting part of RFC1710 looks like section 5. However, section 5 doesn't describe any backwards compatibility that "counts", under your definition. It describes SIPP versions of dual stack (element 1), 6to4 (element 2), dual stack again (element 3), NAT64 (element 4) and I'm not sure about element 5 but it says "does not look like it will be needed" so I'm not sure the mechanism there was ever even developed.
Dual stack, 6to4 and NAT64 are all things that we have already in v6, and I argued above that they are backwards compatibility, but you claimed that they weren't "in the ways that count", and I agreed to go along with that for the time being. So... by your own definition, these don't count.
Presumably, then, you weren't referring to section 5 of RFC1710 when you linked me to it. Could you tell me which sections of the RFC you were thinking about, that describe a method of backwards compatibility that counts under your definition? Or perhaps just describe the mechanism itself?
(I also went through the first few sections of the IPAE whitepaper, but again it doesn't seem to describe any mechanism that would qualify. Again, if I'm wrong then please point me to the relevant part.)
>> there's nothing that v6 could have done to avoid i > Intellectually embarrassing claim for you to make.
The claim is essentially the pigeonhole principle, which isn't intellectually embarrassing in the slightest. You clearly believe the pigeonhole principle is either wrong or can be sidestepped here, but your inability to articulate how is doing a poor job of convincing me that you know how, or even that such a method exists.
(Of course it can be sidestepped with methods like 6to4, but we need a method that "counts", and so far you haven't been able to describe one despite being given ample opportunity to do so.)
If you're only going to compare the local part of the address, then it's 9 digits for v4 vs 2 digits for v6. Comparing the local part of the v4 address pair with the full v6 address isn't a fair comparison.
Notice how they all have the same prefix, with just a 1 digit difference at the end? And while I'm here, notice how the v4 addressing is actually longer? If you can handle v4 then you can handle v6.
Alright, let's go with that for now. The next question is: what could they possibly have done about it?
v4 isn't forwards compatible, and doesn't support anything more than 32 bits of addresses. This is ultimately a flaw in v4, and there's nothing that v6 could have done to avoid it. What should the designers of v6 have done to avoid this problem? What changes could have been made to make it backwards compatible?
> They really really should have engineered some sort of backward-compatibility into it
It's really easy to say this, but if you sit down and think about it you'll realize that it's not possible to do. v4 isn't forwards compatible, so v6's hands are tied, and there's nothing that anybody could've done about that or could do about it in the future because it's not due to any flaw in v6 but rather due to a flaw in v4. Criticizing v6's designers for not doing something that's impossible seems incredibly unfair to me.
If you think you have a way of doing it, then great -- share it. I keep asking people to do this, and for some reason they never actually do.
(Also, if you think v6 adoption is still relatively low then you haven't been paying any attention to the stats. Google's published statistics are a little bit under 25% worldwide, and Facebook are seeing days where their US traffic is primarily v6. Those numbers should be higher, but they're not exactly low.)
I just went over a bunch of ways in which it isn't incompatible. Do those not count?
Perhaps you could explain how it could've been made any more compatible than it already is? I don't mind how many syllables you use, so long as you describe something that would actually work.
Slashdot Mirror
I'll bet it's not.
It's trivially easy to exhaustively scan the entire v4 internet space. Trying to do the same to the v6 space isn't going to work. There are ways to pare down the search space somewhat, but ultimately Shodan is going to be listing every single exposed v4 service but not very many of the v6 ones.
It doesn't even do that much. The only thing this feature does is, if an MITM is detected, to change the text on the "unrecognized issuer" error page. You won't see the MITM detected error except in situations where you would otherwise be getting an unrecognized issuer error. You're just getting a slightly nicer error message.
'Trusted' MITM already requires you to install the MITM cert manually to avoid getting unrecognized issuer errors on every page load.
That does not appear to be how it works. From reading the patch: if it fails to connect to the Firefox update service then it records the issuer of the cert that the update service presented. Then, if a future TLS connection fails with an unrecognized issuer and the unrecognized issuer matches the issuer that was recorded from the update service, then it displays the MITM error instead of the unrecognized issuer error.
(The code is here and here.)
The check piggy-backs on one of Firefox's existing phone home mechanisms, and it doesn't involve reporting every cert you see to some third party.
This is pretty obviously not the case, because Firefox still supports bootstrapped extensions (which is the technology used to do old extensions and UI customization). They've been limited to extensions signed with a special Mozilla key, because obviously WEs are perfect and everybody should use them except for Mozilla themselves who get special treatment, but they're still supported.
If Firefox can get its current performance while still supporting bootstrapped extensions, then clearly it's possible to get its current performance while still supporting bootstrapped extensions. The speed improvements come from things that can be done at the same time as supporting bootstrapped extensions.
The reason projects like Pale Moon don't get the same improvements is because the patches to do so are huge and integrating them without also integrating the changes that screw up UI appearance is an incredibly complicated job that takes more manpower than they have available.
Which would shade houses from the sun, reducing the need for air conditioning in summer. I'd call that a win.
No, we wouldn't have plenty of space. A v4 /8 is only 16 million addresses, and before RIR runout back in 2011 we were going through those /8s in less than a month each. Demand has only gone up since then, and it's reasonable to believe that a v4 /8 would be something around a two-week supply of IPs at today's usage rates. There are only maybe 20 or so /8s held by companies, so that would be less than a year worth of addresses. The v4 space is simply too small, no matter how you slice and dice it.
And don't worry; we did learn our lessons. You don't see anybody giving out /8s in v6, do you? Nobody is getting that large a fraction of the v6 space.
(Expanding TCP wouldn't be any help either. Our problem isn't TCP port numbers, which we have more than enough of; it's IP addresses.)
Based on this article, I can believe they shipped flawed CPUs without knowing about the flaws. However, if so, it's because they deliberately stopped investing as much effort into finding the flaws in the first place.
And they certainly knew what they were doing when they scaled back their validation.
What I meant was, you didn't seem to have followed it through to the conclusion. It's easy to say "obviously you arrange things so that", but when you start trying to work out what the wire protocol will look like in order to do that, it seems to me that it's going to look very much like v6 already does. (If not, feel free to explain how you'd do it.)
Ah, so you did have the start of an idea... but I'm not really seeing how it differs from dual stack. It looks like you're suggesting to have an unmodified v4 stack to handle talking to v4 hosts, plus an "extended v4" stack to handle talking to v6 hosts. Or perhaps you're suggesting combining them into the same piece of code, but even if you did that, so long as you're using two different addresses and are talking two different wire protocols then it's still effectively dual stack. Calling it something different doesn't help.
How does your suggestion let v6 hosts talk to v4 hosts? "By using v4", okay. How does it let v4 hosts talk to v6 hosts? I don't see a way of making that work that isn't "by using v6". And how do routers handle routing it? Again it seems to require that the router do v6. If there's a difference in the backwards compatibility afforded by this vs by dual stack, I'm having trouble seeing it. What's the difference that I'm missing?
I'm willing to try, and I have tried, but I very quickly hit the pidginhole principle and I can't think of any way around that other than the ways that we are already using. I've gone over other people's suggestions too, but they generally either don't work or they suffer from the same issues that v6 already suffers from.
And you're right, I don't know that you haven't come up with anything. I just don't get why you'd keep it to yourself if you had.
So you at least agree that it exists, and neither of us have been able to come up with any better ways of doing it so it seems likely that it's about as good as it can get. I guess you can argue it's not good enough, but if it can't be made any better then you can't really criticize v6 for not making it any better. (Instead, criticize v4 for not allowing any better mechanism.)
I'd say that dual stack never was necessary. It has always been possible to remove v4 from your network; v6 doesn't force you to keep it. The fact that I'm running a single-stack v6 desktop right now, with access to v4-only sites, demonstrates that. It's just that it's the only real way to keep existing v4-only software and devices working, and if that's something that you care about then what better choice do you have? If you do in fact have a better option then I'm all ears, but I'm not sure what you could possibly do that would work with existing v4-only stuff.
464XLAT support in OSs would've been, and would still be, really damn useful for dealing with v4-only software, but that doesn't help v4-only devices.
It sounds like you've done a 180 and now agree that v6's backwards compatibility does in fact exist and works well enough, even though it doesn't and can't work perfectly (like I pointed out at the beginning and have been pointing out the whole time). That's good to hear, even though your attitude sure doesn't suggest you've realized that you've done it.
Incidentally, I posted this from a machine that only has v6. Slashdot works fine from this machine, and in fact I've yet to find a website that doesn't work from it. How is that an island, any more so than NAT44 already is?
It sounds like "natural oligopoly" would indeed be more to your taste then.
You're right that regulatory capture also tends to raise the barrier to entry, and that's obviously a problem, but let's not pretend that it's the only barrier to entry involved in doing last-mile telecommunications. You can fix the regulatory capture issue, but burying thousands of miles of fibre is still inherently going to be expensive -- that's the "natural" part (as opposed to the regulatory capture, which obviously isn't natural).
To respond in kind: if it's not a natural monopoly, how do you not have dozens of choices? I have a choice of something like 50 ISPs.
Perhaps calling it a "naturally monopolistic market", or a "natural oligopoly" would be more to your taste. The point is that there's a high barrier to entry due to the costs of physically sticking cables in the ground, and getting rid of anti-competition regulation doesn't make those costs go away.
Except for the part where last-mile cabling is a natural monopoly. Fix that, and then I'd agree with you.
I already mentioned, multiple times, tunnelling and NAT as viable backwards compatibility options that are already available in v6, but if you remember, I asked you if those counted and your response was "In the ways that count, ipv6 is incompatible" and you called me stupid for mentioning them as a way to do backwards compatibility.
That's why I've been asking you to tell us your idea for making it compatible in a way that you consider as counting -- because as far as I can tell it's not possible to do, and I don't think it's fair in the slightest to blame v6 for not doing something that's not possible in the first place. Or are you now admitting that 6to4 and NAT64 actually do count as backwards compatibility?
Embedding v4 into the v6 space is easy enough, but how does that get you backwards compatibility? We already have ::ffff:<v4 addr> which does the embedding, but how do you enable two-way communication? If you could somehow also embed v6 into the v4 space then it'd be pretty easy, but there's not enough space in v4 to do that (if there was we wouldn't need v6 in the first place).
This post is either the 4th or the 5th time that I've asked you to describe a way of doing backwards compatibility in a way that would satisfy you. I think it's about time you either did so, or admitted that v6 is already doing the best backwards compatibility that it can given the constraints that it's working under.
The logic is pretty well-supported: v4 is limited to 32 bit addresses, so there's no way for it to specify which v6 host it wants to communicate with. That, right there, kills your ability to do perfect backwards compatibility. There are some ways around that limitation, but v6 implements those ways and you already dismissed them as not counting further up.
If you think it's possible to do full backwards compatibility in a way that you'd accept, then you could easily convince us by just describing a way to do it (a valid way, one that works and doesn't have the limitations of the existing ways). The fact that you can't -- and then call us incompetent, as if it was our fault that you can't answer -- just makes it more and more obvious that you don't actually have a way to do it.
Both stateful firewalling and NAT require state tracking, so they're often implemented in the same piece of software or hardware. Nevertheless, the firewalling and the NAT parts are logically separate components. The NAT part is responsible for rewriting addresses, and the firewall part is responsible for deciding which packets to drop.
Crazy idea: if nobody can do any better, then maybe they didn't fuck it up? Maybe they already did make it as good as it could possibly be.
Perhaps you could spend less time insulting me (and Vint Cerf; what on earth did that man do to you?) and more time answering the question.
Dumping 80 pages of whitepaper on me isn't very reasonable, but okay, I went through it. The interesting part of RFC1710 looks like section 5. However, section 5 doesn't describe any backwards compatibility that "counts", under your definition. It describes SIPP versions of dual stack (element 1), 6to4 (element 2), dual stack again (element 3), NAT64 (element 4) and I'm not sure about element 5 but it says "does not look like it will be needed" so I'm not sure the mechanism there was ever even developed.
Dual stack, 6to4 and NAT64 are all things that we have already in v6, and I argued above that they are backwards compatibility, but you claimed that they weren't "in the ways that count", and I agreed to go along with that for the time being. So... by your own definition, these don't count.
Presumably, then, you weren't referring to section 5 of RFC1710 when you linked me to it. Could you tell me which sections of the RFC you were thinking about, that describe a method of backwards compatibility that counts under your definition? Or perhaps just describe the mechanism itself?
(I also went through the first few sections of the IPAE whitepaper, but again it doesn't seem to describe any mechanism that would qualify. Again, if I'm wrong then please point me to the relevant part.)
>> there's nothing that v6 could have done to avoid i
> Intellectually embarrassing claim for you to make.
The claim is essentially the pigeonhole principle, which isn't intellectually embarrassing in the slightest. You clearly believe the pigeonhole principle is either wrong or can be sidestepped here, but your inability to articulate how is doing a poor job of convincing me that you know how, or even that such a method exists.
(Of course it can be sidestepped with methods like 6to4, but we need a method that "counts", and so far you haven't been able to describe one despite being given ample opportunity to do so.)
If you're only going to compare the local part of the address, then it's 9 digits for v4 vs 2 digits for v6. Comparing the local part of the v4 address pair with the full v6 address isn't a fair comparison.
So not really any different then.
Here's the v4 address of my desktop, compared to the v6 address:
203.0.113.42+192.168.1.2, vs
2001:db8:42:1::2
And here are some of the other IPs of machines on the network:
2001:db8:42:1::3
2001:db8:42:1::4
2001:db8:42:1::5
2001:db8:42:1::6
Notice how they all have the same prefix, with just a 1 digit difference at the end? And while I'm here, notice how the v4 addressing is actually longer? If you can handle v4 then you can handle v6.
Alright, let's go with that for now. The next question is: what could they possibly have done about it?
v4 isn't forwards compatible, and doesn't support anything more than 32 bits of addresses. This is ultimately a flaw in v4, and there's nothing that v6 could have done to avoid it. What should the designers of v6 have done to avoid this problem? What changes could have been made to make it backwards compatible?
> They really really should have engineered some sort of backward-compatibility into it
It's really easy to say this, but if you sit down and think about it you'll realize that it's not possible to do. v4 isn't forwards compatible, so v6's hands are tied, and there's nothing that anybody could've done about that or could do about it in the future because it's not due to any flaw in v6 but rather due to a flaw in v4. Criticizing v6's designers for not doing something that's impossible seems incredibly unfair to me.
If you think you have a way of doing it, then great -- share it. I keep asking people to do this, and for some reason they never actually do.
(Also, if you think v6 adoption is still relatively low then you haven't been paying any attention to the stats. Google's published statistics are a little bit under 25% worldwide, and Facebook are seeing days where their US traffic is primarily v6. Those numbers should be higher, but they're not exactly low.)
I just went over a bunch of ways in which it isn't incompatible. Do those not count?
Perhaps you could explain how it could've been made any more compatible than it already is? I don't mind how many syllables you use, so long as you describe something that would actually work.