From a business perspective, that may not be too crazy. Not because PCs/Laptops are dropping in popularity, but because new purchases are starting to decline (i.e. more and more people replace when broken instead of replace just to be faster). I do not believe people are throwing out their laptops and desktops and switching all over to TVs, Phones, Tablets, and so forth, but the business world becomes quickly disinterested in a market of markedly lower new sales.
It gets worse as it goes. So first we say they need WP7 UI (which is the last UI I'd envy) on webOS core, but modernized (basically claiming the core is good, but not good at all... internally inconsistent), then goes on to say how HP needs to get away from Microsoft (the recommendation to 'buy' Windows Phone 7 UI seems to fly directly in the face of that.
What HP has to do is simple, and it might be too late. They need to release hardware that actually is on par with the industry (still no autofocus notably, and somewhat underpowerd CPU/GPU) and they need to basically continue the vision that was getting better on software (the HTML+Javascript *only* api was a disaster). With the brain-drain that obviously followed in the months after the acquisition, the webOS platform may be unsalvagable (*particularly* with a new CEO at HP pretty much explicitly saying the consumer space is less interesting).
So I have a WebOS phone. I find the multi-tasking interface and frankly the menu for quick changes to the radio highly enjoyable. I took it for granted until I tried to navigate around on an Android phone. WebOS (and Blackberry is imitating it on Playbook) has a great way to interact with concurrently running apps and switching between them in full screen mode. The radio menu I didn't think was special, then I found myself working on an Android phone and having to jump out of the menu to go to system settings to do something with bluetooth that was much more immediately accessible on my Pre. Also, surprisingly, my phone had LEAP wireless support out of the gate and my peers were having to try to hand hack wpa_supplicant.conf to get the function out of their Android handsets, that didn't work out of the box. WebOS 2 has Cisco Anyconnect support baked in, but Android is not there yet either. The messaging app does a good job of putting everything (SMS, AIM, jabber, whatever) in one coherent interface.
From an API perspective, they completely screwed up by *not* having the 'PDK' from the get go. They foolishly thought Javascript+HTML5 was 'good enough', with no camera api, no microphone api, no 3D api. Their hardware features crappy, fixed-focus cameras. They rectified mostly the software side, with a nice OpenGL+SDK that makes it trivial to port linux apps (and evidentally iOS), but desperately need decent hardware. One thing they did *almost* just right was the integration of inductiive charging into the experience. They should never have had a non-capable back part, they should have had third-party access (added in WebOS 2), and they should have officially blessed a car-oriented usage of the technology.
So the big thing is they nailed the UI. On the surface, however, the 'big names' that created that have been poached. It's hard to say what will happen now. Microsoft and Google do have the disadvantage that they can't dictate every nth detail to the handset makers, which gives Blackberry, HP, and, of course, Apple, an interesting advantage for the most seamless experience. Apple's vision is clear and I'm not a fan of it myself, so I like an alternative. Palm came closest, but I don't know how Honeycomb, WebOS 2, and the next wave of Blackberry devices will pan out.
WebM is an open 'proprietary' implementation. It can easily be retroactively declared a standard, or achieve defacto standard status, but it is a technology championed by a single company without a standards body overseeing it. This is not necessarily a bad thing (and can even be a good thing, standards bodies frequently mess things up). It is unarguably open, but it isn't standard.
One could make the case that h264 is not 'open', because of the royalties, but it *is* a standard because the work was done with the standards bodies to make it so.
He does point out the obvious that the rhetoric of 'we believe in open' is really better read as 'we are too cheap for licensing decoders for a free browser', but that one sentence was really all that needed to be said on the matter and most people immediately realized that.
That ignores the fact that more and more web access, *particularly* for youtube-type content is coming from embedded style devices (phones, TVS, etc), which generally are not so straightforward and may even be incapable of dealing with a different format even with a hypothetical firmware upgrade.
The short of it is, Google is in no way going to try to stupidly use youtube as a 'weapon' like that because they aren't complete morons. Just like MS using that statistic borders on the pointless as those video sites aren't using browser-native HTML5 to play it back on a desktop browser *anyway*.
If IPv6 is cheaper for them to do, and NAT66 isn't commonly available, then you bet your ass they will. They know well that some number of devices greater than one always access their service. They don't want to bridge customer networks together in a layer 2 sense, so they will delegate prefixes for use by linksys gateways and the like. IPv6 explicitly made efforts so that prefix delegation is trivially automatic, so there isn't work associated with it, and addresses are so bountiful there simply is no point in *not* doing it.
They'll celebrate the fact that Youtube suicided, or won't be impacted at all.
The former will happen if they did that move without Adobe supporting it in flash. It may well still happen because all the iPhones and similar in the world suddenly couldn't play youtube content because they depended on efficient ASICs that can't be adapted to WebM and there isn't enough generic processing power to do it without such an ASIC.
The latter will happen if they figure a way around it on mobile devices, and have a flash update enable it for all browsers which will render the difference between IE and Chrome moot once again.
MS considers their position to be perfectly opposite to google. No matter what choice google makes, MS will try to find a way to spin it as wrong and completely distinct from their own stance.
Here, MS has by many measurements, less than 50% share, and Chrome, Firefox, and Safari all reject H264, meaning it actually has a shot.
That shot is small, as practically speaking, all this HTML5 video stuff is mostly moot with 100% of those video sites using flash players, which gives not a rat's ass about any of this. This move will only reinforce Adobe's position.
Also, I wonder why the hell the browser vendors did not link into Quicktime, MS's media framework, and gstreamer respectively for their OSX, Windows, 'other' video support, instead of all this BS that won't work out well.
Right, but if they are wanting to do analytics, they use long lived tracking cookies today. They already do all the tracking they need to do at the HTTP/Browser layer. A better argument would be that users can at least opt out by controlling their acceptance of cookies, even if no one does as in practice it breaks too many sites to blanket deny and way too many questions to consider one at a time.
The sad fact is that NAT gives very little protection in practice against things like tracking, *particularly* to the home market, where household granularity in tracking is quite sufficient no matter how you look at it.
Android is a Linux phone. However, that doesn't mean a vendor won't try to lock it down. They still can 'Tivo-ize' it, and keep all access to the filesystem locked down. I think currently at least side-loaded apps are possible everywhere *but* WP7 and iPhone, but it is advisable to be aware that Linux != open hardware.
1) Whether it is an IPv6 address or an IPv4address+DNAT port, the exposure is the same, the outside world has a door into a specific system.
My thought is that running an open wifi does not provide plausible deniability. It's more likely that someone will do something malicious behind your gateway and you'll take the blame than vice-versa. *Especially* if you seem technically capable, the fact that you explicitly left your wifi open would be taken as a sign you were *trying* for plausible deniability. Face it, for the residential case, *there is no plausible deniability*, at least with respect to traffic that originates from your residence, *unless* you have a trusted proxy shared with others out there that you *know* won't retain enough data to trace your identity. The only way to have plausible deniability is to find an open-wifi somewhere and hope there's no security camera. If it is some poor sap's house, then they will probably get blamed, if a business, that business may be required to discontinue open wifi under legal pressure.
If you did want to put your static address into your firewall rules, you could do the exact same strategy as IPv4, either staticly decide your IP (which is still very much possible) or use DHCPv6 to assign addresses. The entire IPv6 world isn't just the stuff defined in stateless auto-addressing.
My counterpoint would be that websites can and already do track individual machine accesses via session cookies, and can develop a pattern from that just as easily as by IP.
However, I personally would not be adverse to NAT66 being implemented commonly, but I think there is a fear that if NAT66 exists, the ISPs will bone the residential market that includes the people who really want an actual usable subnet for their home.
Ok, but what if you wanted to hypothetically print a form you had open on your cell phone *right now* wherever you are for later review? Might be nice to actually be able to reach your printer then, so long as it is properly secured.
And what prey tell should I do for my PC ? Set a static ipv6 address to be entered into the whitelist ?
How is that different from your NAT today? If you want to accept incoming connections, you must tell your NAT box a port to DNAT map from your external thing to something internal, defined by, surprise surprise, a static entry.
If you are talking about *outgoing* traffic, I'd say the default is to allow outgoing if you just want to mimick NAT 'security' out of the box.
I think it's far easier to let NAT66 exist, let corporations that want it have it, and let residences like mine decide between NAT66 and doing it the easy way. If renumbering is not going to work right or at least no one wants to run the requisite test or accept the risk, then NAT66 is far better than every mom and pop shop demanding provider-independent space.
My sig has been like that for a long long while. I think I might have stolen it but cannot recall from where.
I agree with you, but will also point out for the NAT fanatics that IPv6 makes the case you described better. With fd::/8 ULA, your work, university, and secret club will have/48s that have a near zero chance of colliding with each other or the random ULA prefix you get at home.
Ok, that VLAN comment was odd. VLAN is a construct where an ethernet switch can manage a broadcast domain in a manner distinct from the specific physical layout. One switch can present three broadcast domains, different VLANs can be aggregated over various things to acheive complicated things. VLAN has nothing to do with a router, unless you are doing some sort of layer 2 tunneling, which I still cannot logically tie to what the grandparent post said in any way.
NAT doesn't make anything easier except hiding how many systems are behind a gateway. NAT is just a pain in the ass that is accepted and a one-rule firewall is just as capable and requires no special treatment regardless of where the device goes. For example, if your linksys box choses 192.168 by default, but you are plugging it into a network that also uses 192.168, you must reconfigure. A linksys getting a delegated v6 prefix never has to bother the administrator for a different firewall rule because it somehow magically conflicts with the context it is applying to.
All the practical security concerns seem moot with the reality that 'reject unsolicited incoming traffic' is sufficient to get the commonly perceived 'security' benefit of NAT. At the same time as I agree that people have overblown the inherent security of NAT over 'plain ol' firewalling, I do kinda wish that a blessed NAT66 RFC would exist so that people would just shut the hell up about it, but at the same time am afraid any hope of getting my/56 to use the *right* way will evaporate when that happens.
Yes, they are thinking it through. There have been blind eyes to various things as some people wanted to bathe in the theory of how they thought it *should* work, but most concerns you have are considered and have reasonable answers.
At least you hit on the one facet of security that NAT does at least help with, more accurately measuring how many hosts are beyond a particular gateway. I do wonder what the practical risk is there, however. If you are doing non-privacy stateless addressing, ok it divulges your hardware address, but I'd advocate for either the privacy autoaddressing or DHCP range which has nothing to do with your system and moves that entirely onto site-persistent selection instead of device-persistent selection.
If you have an internal-only service on a system that you don't want routable at all to internet, just do either the fe80:: address (which admittedly could be awkward with the required zone index suffix) or generate a ULA out of fd00:/8. Either way you slice it, you have a non-routable IPv6 host. If you are concerned that your hosts need aliased addressing and that's "weird", well, all IPv6 hosts will at least have two 'aliases', one in fe80:: world and one global, and aliasing is more 'mainstream' in IPv6 thinking.
Finally, IPv6 to IPv6 NAT should exist, so you could have exactly your analogous config, with an fd<whatever> address on the inside and dynamic mapping to external address space, but *please* don't make that so ubiquitous so that your hangups on how IPv6 needs to act exactly like IPv4 get in the way of me getting my/56 at my house one day.
Your 'gate' is your router/firewall. People can't magically get around the same exact piece of equipment that NATs today simply because they are independently addressable. Those devices need to just have a 'no unsolicited incoming traffic' firewall by default.
Except that fc00::/8 is *not* supposed to be used at all right now, and when if it is, then all users *must* use a central registrar to assure uniqueness.
*Now* fd00:/8 Could be an issue. Ostensibly, following the rules a program is supposed to spew out your prefix instead of being manual choosing. So a lot of private network type devices that formerly just defaulted to 192.168.0.0 would instead default to some/48 out of fd chosen psuedo randomly, but the call for such a default network is greatly reduced with fe80:: link-local addressing. Leaving most private networks being a conscious choice, and drawing fd instead of running a utility I could see becoming a best practice in spite of the 'requirements' that people not do that given the inherent honor system of that whole thing.
Ignore his first point, focus on the second. Everywhere you put a NAT for security today, have a default firewall set. Home routers deny any unsolicited traffic by default. There you go, all the security of NAT with *zero* of the PITA.
Windows 7 and Windows Server 2008R2 I know by default will DHCPv6.
I believe RHEL5 and newer also DHCPv6 by default unless you tell it otherwise.
If you enable IPv6 at all in ESXi, it will DHCP. IPv6 is off by default completely, so DHCPv6 is no more harder to get then anything else.
'ifconfig up' (note ifconfig, not ifup) will start the autoconfig stuff for routers, but generally ifup will end up with DHCP solicits being sent.
In short, either a router advertising the prefix and relying on stateless auto configuration *or* DHCPv6 will get clients on the network. If an interface does DHCP solicits and noone answers, but radvd or similar provide enough info, no biggie.
I have to agree that in theory, autoconfig would address many issues. Practically speaking, I think a lot of admins without thinking use DHCP as more than just a way to describe settings to systems, but as an authoritative aggregation of all that information in one place. You can aggregate on the fly, but it feels more concrete and under control if a DHCP infrastructure handles it. I think there was a lot of optimisim around stateless autoconfig, but DHCP was needed for various hard technical and some 'comfort' reasons.
Also, many environments would want to filter things like DHCPOFFERS, to avoid rogue services advertising and hijacking clients (generally by mistake, occasionally with malice). Autoconf makes them a bit edgy because that's a lot more complicated to control than a single protocol unless a single point of entry does all the services they want to allow to advertise.
Also, for my house, I think DHCP is the only automatic way for a random best buy router to theoretically get a subnet delegated instead of a single address out of my ISP.
Well, replace site local with ULA, but generally I agree. If you didn't need DNS before, you don't need DNS now. There may be extremely small corner cases where very few people with only very few systems to think about would not have set up DNS and used IP, and to this day I don't see mDNS frequently automatically working, so I guess they could complain that fd2d:c747:f314:d001::dead:beef is harder to remember than 10.0.1.7 (yes, both are examples I really use and yes, I did remember my IPv6 address I used without looking it up anywhere).
Slashdot Mirror
Post-PC? Please.
From a business perspective, that may not be too crazy. Not because PCs/Laptops are dropping in popularity, but because new purchases are starting to decline (i.e. more and more people replace when broken instead of replace just to be faster). I do not believe people are throwing out their laptops and desktops and switching all over to TVs, Phones, Tablets, and so forth, but the business world becomes quickly disinterested in a market of markedly lower new sales.
It gets worse as it goes. So first we say they need WP7 UI (which is the last UI I'd envy) on webOS core, but modernized (basically claiming the core is good, but not good at all... internally inconsistent), then goes on to say how HP needs to get away from Microsoft (the recommendation to 'buy' Windows Phone 7 UI seems to fly directly in the face of that.
What HP has to do is simple, and it might be too late. They need to release hardware that actually is on par with the industry (still no autofocus notably, and somewhat underpowerd CPU/GPU) and they need to basically continue the vision that was getting better on software (the HTML+Javascript *only* api was a disaster). With the brain-drain that obviously followed in the months after the acquisition, the webOS platform may be unsalvagable (*particularly* with a new CEO at HP pretty much explicitly saying the consumer space is less interesting).
So I have a WebOS phone. I find the multi-tasking interface and frankly the menu for quick changes to the radio highly enjoyable. I took it for granted until I tried to navigate around on an Android phone. WebOS (and Blackberry is imitating it on Playbook) has a great way to interact with concurrently running apps and switching between them in full screen mode. The radio menu I didn't think was special, then I found myself working on an Android phone and having to jump out of the menu to go to system settings to do something with bluetooth that was much more immediately accessible on my Pre. Also, surprisingly, my phone had LEAP wireless support out of the gate and my peers were having to try to hand hack wpa_supplicant.conf to get the function out of their Android handsets, that didn't work out of the box. WebOS 2 has Cisco Anyconnect support baked in, but Android is not there yet either. The messaging app does a good job of putting everything (SMS, AIM, jabber, whatever) in one coherent interface.
From an API perspective, they completely screwed up by *not* having the 'PDK' from the get go. They foolishly thought Javascript+HTML5 was 'good enough', with no camera api, no microphone api, no 3D api. Their hardware features crappy, fixed-focus cameras. They rectified mostly the software side, with a nice OpenGL+SDK that makes it trivial to port linux apps (and evidentally iOS), but desperately need decent hardware. One thing they did *almost* just right was the integration of inductiive charging into the experience. They should never have had a non-capable back part, they should have had third-party access (added in WebOS 2), and they should have officially blessed a car-oriented usage of the technology.
So the big thing is they nailed the UI. On the surface, however, the 'big names' that created that have been poached. It's hard to say what will happen now. Microsoft and Google do have the disadvantage that they can't dictate every nth detail to the handset makers, which gives Blackberry, HP, and, of course, Apple, an interesting advantage for the most seamless experience. Apple's vision is clear and I'm not a fan of it myself, so I like an alternative. Palm came closest, but I don't know how Honeycomb, WebOS 2, and the next wave of Blackberry devices will pan out.
WebM is an open 'proprietary' implementation. It can easily be retroactively declared a standard, or achieve defacto standard status, but it is a technology championed by a single company without a standards body overseeing it. This is not necessarily a bad thing (and can even be a good thing, standards bodies frequently mess things up). It is unarguably open, but it isn't standard.
One could make the case that h264 is not 'open', because of the royalties, but it *is* a standard because the work was done with the standards bodies to make it so.
He does point out the obvious that the rhetoric of 'we believe in open' is really better read as 'we are too cheap for licensing decoders for a free browser', but that one sentence was really all that needed to be said on the matter and most people immediately realized that.
That ignores the fact that more and more web access, *particularly* for youtube-type content is coming from embedded style devices (phones, TVS, etc), which generally are not so straightforward and may even be incapable of dealing with a different format even with a hypothetical firmware upgrade.
The short of it is, Google is in no way going to try to stupidly use youtube as a 'weapon' like that because they aren't complete morons. Just like MS using that statistic borders on the pointless as those video sites aren't using browser-native HTML5 to play it back on a desktop browser *anyway*.
If IPv6 is cheaper for them to do, and NAT66 isn't commonly available, then you bet your ass they will. They know well that some number of devices greater than one always access their service. They don't want to bridge customer networks together in a layer 2 sense, so they will delegate prefixes for use by linksys gateways and the like. IPv6 explicitly made efforts so that prefix delegation is trivially automatic, so there isn't work associated with it, and addresses are so bountiful there simply is no point in *not* doing it.
They'll celebrate the fact that Youtube suicided, or won't be impacted at all.
The former will happen if they did that move without Adobe supporting it in flash. It may well still happen because all the iPhones and similar in the world suddenly couldn't play youtube content because they depended on efficient ASICs that can't be adapted to WebM and there isn't enough generic processing power to do it without such an ASIC.
The latter will happen if they figure a way around it on mobile devices, and have a flash update enable it for all browsers which will render the difference between IE and Chrome moot once again.
MS considers their position to be perfectly opposite to google. No matter what choice google makes, MS will try to find a way to spin it as wrong and completely distinct from their own stance.
Here, MS has by many measurements, less than 50% share, and Chrome, Firefox, and Safari all reject H264, meaning it actually has a shot.
That shot is small, as practically speaking, all this HTML5 video stuff is mostly moot with 100% of those video sites using flash players, which gives not a rat's ass about any of this. This move will only reinforce Adobe's position.
Also, I wonder why the hell the browser vendors did not link into Quicktime, MS's media framework, and gstreamer respectively for their OSX, Windows, 'other' video support, instead of all this BS that won't work out well.
Right, but if they are wanting to do analytics, they use long lived tracking cookies today. They already do all the tracking they need to do at the HTTP/Browser layer. A better argument would be that users can at least opt out by controlling their acceptance of cookies, even if no one does as in practice it breaks too many sites to blanket deny and way too many questions to consider one at a time.
The sad fact is that NAT gives very little protection in practice against things like tracking, *particularly* to the home market, where household granularity in tracking is quite sufficient no matter how you look at it.
Android is a Linux phone. However, that doesn't mean a vendor won't try to lock it down. They still can 'Tivo-ize' it, and keep all access to the filesystem locked down. I think currently at least side-loaded apps are possible everywhere *but* WP7 and iPhone, but it is advisable to be aware that Linux != open hardware.
1) Whether it is an IPv6 address or an IPv4address+DNAT port, the exposure is the same, the outside world has a door into a specific system.
My thought is that running an open wifi does not provide plausible deniability. It's more likely that someone will do something malicious behind your gateway and you'll take the blame than vice-versa. *Especially* if you seem technically capable, the fact that you explicitly left your wifi open would be taken as a sign you were *trying* for plausible deniability. Face it, for the residential case, *there is no plausible deniability*, at least with respect to traffic that originates from your residence, *unless* you have a trusted proxy shared with others out there that you *know* won't retain enough data to trace your identity. The only way to have plausible deniability is to find an open-wifi somewhere and hope there's no security camera. If it is some poor sap's house, then they will probably get blamed, if a business, that business may be required to discontinue open wifi under legal pressure.
If you did want to put your static address into your firewall rules, you could do the exact same strategy as IPv4, either staticly decide your IP (which is still very much possible) or use DHCPv6 to assign addresses. The entire IPv6 world isn't just the stuff defined in stateless auto-addressing.
My counterpoint would be that websites can and already do track individual machine accesses via session cookies, and can develop a pattern from that just as easily as by IP.
However, I personally would not be adverse to NAT66 being implemented commonly, but I think there is a fear that if NAT66 exists, the ISPs will bone the residential market that includes the people who really want an actual usable subnet for their home.
Ok, but what if you wanted to hypothetically print a form you had open on your cell phone *right now* wherever you are for later review? Might be nice to actually be able to reach your printer then, so long as it is properly secured.
And what prey tell should I do for my PC ? Set a static ipv6 address to be entered into the whitelist ?
How is that different from your NAT today? If you want to accept incoming connections, you must tell your NAT box a port to DNAT map from your external thing to something internal, defined by, surprise surprise, a static entry.
If you are talking about *outgoing* traffic, I'd say the default is to allow outgoing if you just want to mimick NAT 'security' out of the box.
I think it's far easier to let NAT66 exist, let corporations that want it have it, and let residences like mine decide between NAT66 and doing it the easy way. If renumbering is not going to work right or at least no one wants to run the requisite test or accept the risk, then NAT66 is far better than every mom and pop shop demanding provider-independent space.
My sig has been like that for a long long while. I think I might have stolen it but cannot recall from where.
I agree with you, but will also point out for the NAT fanatics that IPv6 makes the case you described better. With fd::/8 ULA, your work, university, and secret club will have /48s that have a near zero chance of colliding with each other or the random ULA prefix you get at home.
Ok, that VLAN comment was odd. VLAN is a construct where an ethernet switch can manage a broadcast domain in a manner distinct from the specific physical layout. One switch can present three broadcast domains, different VLANs can be aggregated over various things to acheive complicated things. VLAN has nothing to do with a router, unless you are doing some sort of layer 2 tunneling, which I still cannot logically tie to what the grandparent post said in any way.
NAT doesn't make anything easier except hiding how many systems are behind a gateway. NAT is just a pain in the ass that is accepted and a one-rule firewall is just as capable and requires no special treatment regardless of where the device goes. For example, if your linksys box choses 192.168 by default, but you are plugging it into a network that also uses 192.168, you must reconfigure. A linksys getting a delegated v6 prefix never has to bother the administrator for a different firewall rule because it somehow magically conflicts with the context it is applying to.
All the practical security concerns seem moot with the reality that 'reject unsolicited incoming traffic' is sufficient to get the commonly perceived 'security' benefit of NAT. At the same time as I agree that people have overblown the inherent security of NAT over 'plain ol' firewalling, I do kinda wish that a blessed NAT66 RFC would exist so that people would just shut the hell up about it, but at the same time am afraid any hope of getting my /56 to use the *right* way will evaporate when that happens.
Yes, they are thinking it through. There have been blind eyes to various things as some people wanted to bathe in the theory of how they thought it *should* work, but most concerns you have are considered and have reasonable answers.
At least you hit on the one facet of security that NAT does at least help with, more accurately measuring how many hosts are beyond a particular gateway. I do wonder what the practical risk is there, however. If you are doing non-privacy stateless addressing, ok it divulges your hardware address, but I'd advocate for either the privacy autoaddressing or DHCP range which has nothing to do with your system and moves that entirely onto site-persistent selection instead of device-persistent selection.
If you have an internal-only service on a system that you don't want routable at all to internet, just do either the fe80:: address (which admittedly could be awkward with the required zone index suffix) or generate a ULA out of fd00:/8. Either way you slice it, you have a non-routable IPv6 host. If you are concerned that your hosts need aliased addressing and that's "weird", well, all IPv6 hosts will at least have two 'aliases', one in fe80:: world and one global, and aliasing is more 'mainstream' in IPv6 thinking.
Finally, IPv6 to IPv6 NAT should exist, so you could have exactly your analogous config, with an fd<whatever> address on the inside and dynamic mapping to external address space, but *please* don't make that so ubiquitous so that your hangups on how IPv6 needs to act exactly like IPv4 get in the way of me getting my /56 at my house one day.
Your 'gate' is your router/firewall. People can't magically get around the same exact piece of equipment that NATs today simply because they are independently addressable. Those devices need to just have a 'no unsolicited incoming traffic' firewall by default.
err.. I meant selecting fd<favorite hexspeak here> instead of running a utility.
Except that fc00::/8 is *not* supposed to be used at all right now, and when if it is, then all users *must* use a central registrar to assure uniqueness.
*Now* fd00:/8 Could be an issue. Ostensibly, following the rules a program is supposed to spew out your prefix instead of being manual choosing. So a lot of private network type devices that formerly just defaulted to 192.168.0.0 would instead default to some /48 out of fd chosen psuedo randomly, but the call for such a default network is greatly reduced with fe80:: link-local addressing. Leaving most private networks being a conscious choice, and drawing fd instead of running a utility I could see becoming a best practice in spite of the 'requirements' that people not do that given the inherent honor system of that whole thing.
Ignore his first point, focus on the second. Everywhere you put a NAT for security today, have a default firewall set. Home routers deny any unsolicited traffic by default. There you go, all the security of NAT with *zero* of the PITA.
Windows 7 and Windows Server 2008R2 I know by default will DHCPv6.
I believe RHEL5 and newer also DHCPv6 by default unless you tell it otherwise.
If you enable IPv6 at all in ESXi, it will DHCP. IPv6 is off by default completely, so DHCPv6 is no more harder to get then anything else.
'ifconfig up' (note ifconfig, not ifup) will start the autoconfig stuff for routers, but generally ifup will end up with DHCP solicits being sent.
In short, either a router advertising the prefix and relying on stateless auto configuration *or* DHCPv6 will get clients on the network. If an interface does DHCP solicits and noone answers, but radvd or similar provide enough info, no biggie.
I have to agree that in theory, autoconfig would address many issues. Practically speaking, I think a lot of admins without thinking use DHCP as more than just a way to describe settings to systems, but as an authoritative aggregation of all that information in one place. You can aggregate on the fly, but it feels more concrete and under control if a DHCP infrastructure handles it. I think there was a lot of optimisim around stateless autoconfig, but DHCP was needed for various hard technical and some 'comfort' reasons.
Also, many environments would want to filter things like DHCPOFFERS, to avoid rogue services advertising and hijacking clients (generally by mistake, occasionally with malice). Autoconf makes them a bit edgy because that's a lot more complicated to control than a single protocol unless a single point of entry does all the services they want to allow to advertise.
Also, for my house, I think DHCP is the only automatic way for a random best buy router to theoretically get a subnet delegated instead of a single address out of my ISP.
Well, replace site local with ULA, but generally I agree. If you didn't need DNS before, you don't need DNS now. There may be extremely small corner cases where very few people with only very few systems to think about would not have set up DNS and used IP, and to this day I don't see mDNS frequently automatically working, so I guess they could complain that fd2d:c747:f314:d001::dead:beef is harder to remember than 10.0.1.7 (yes, both are examples I really use and yes, I did remember my IPv6 address I used without looking it up anywhere).