Firefox did it first, of course: chrome://browser/content/browser.xul
Firefox did it first, of course: chrome://browser/content/browser.xul
The alternative is to introduce a stable API for extensions to code against if they want to, and make the API powerful enough that most extensions actually can be written with it. And then, for extensions that can't be done in the API, just accept that breakage might happen.
(And note that I said "might", not "will". Many extensions only touch the browser UI and not content pages, and won't be affected by e10s.)
As usual, Mozilla gets most of the way there and then fucks up right at the crucial point; in this case by declaring that if their new API doesn't do the trick, then you can just bugger off somewhere else.
Uh, no. Mozilla tries to fix it by just breaking them once and then never letting anyone fix them*. Everyone not happy, and if that's a WTF to you then I don't know what to say.
*: At least for some subset (the interesting subset) of extensions. Some extensions will be fixable, as they'll merely require a complete rewrite rather then being impossible.
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
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
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
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.
If builders built buildings the way programmers wrote programs, then the first woodpecker to come along would destroy civilization.