Forgot your password?
typodupeerror

Comment: Re:NAT isn't going anywhere (Score 1) 290

by TheCrazyFinn (#34973336) Attached to: Yahoo IPv6 Upgrade Could Shut Out 1M Users
So IPv6 has functional replacements for most of the advantages of NAT, but those functional replacements generate significantly more admin work to implement. For example pseudo-random IP's + local-only addresses to replace NAT's topology-hiding? Gimme a frikkin break. With IPv4+NAT I assign 1 address per machine that's in local DNS/hosts files, is routable across the NAT'd subnet/private network and is fully memorable on smaller networks or any network with standard subnet numbering (.1 is always router, .2 always DNS or some such system). And I can easily track which machines are hitting the internet. With IPv6 I need to assign one ULA IP and then the machine generates its own pseudo-random IP for external access. Neither are human-readable. And tracking internet usage is far more complex since the pseudo-random IP obscures the info from me (a PITA when trying to track down exactly which idiot salesman's laptop is spewing spam out of the network, that's otherwise trivial with a good firewall). And when working behind a proper firewall running 1:1 NAT I'm now losing one of the main benefits of direct IP-private IP mapping, IE I can bring up a replacement server, get it fully running & tested and then swap it into production with a single, instant change on the firewall to switch it up (and a single-line config change to revert) and I'm back to swapping IP's on multiple machines to do this (and this is one of the two main reasons to use NAT in a data centre application, the other being to hide support servers from the outside, which is less of an issue with IPv6 to be sure). So yes, IPv6 has solutions. But they're significantly more labour-intensive than under IPv4.

Comment: Re:We always knew that ipv6 adoption would be mess (Score 1) 376

by TheCrazyFinn (#34972862) Attached to: Last Days For Central IPv4 Address Pool
No, the bulk of changes are in network engineering. Lots of man-hours but low hardware costs. The biggest stumbling block is probably the DHCP issue, two mostly-incompatible specs for IPv6 and neither works as well as plain old IPv4 DHCP. But those issues won't be visible to consumers (large-scale DHCP issues are going to be a big stumbling block for IPv6 uptake in large multi-site organizations, not residential providers who will likely just use IP Autoconfig instead). The other issue is that the lack of IP portability is going to cause some serious re-engineering requirements for multi-nationals (but ISP's are going to LOVE it, it's government-issue spec-level vendor lockin via IP allocation).

Comment: Re:We always knew that ipv6 adoption would be mess (Score 1) 376

by TheCrazyFinn (#34972534) Attached to: Last Days For Central IPv4 Address Pool
No, it's a minimum of 10's of thousands of man-hours of deployment and probably collectively north of a few hundred million in deployment costs (mostly in terms of man-hours of engineering). The hardware isn't a significant cost centre here since it mostly already has support, as does firmware. While IPv6 rollouts are merely an annoyance for small/medium businesses or providers it's a massive project at massive cost for the big providers and also for any organization with more than a few sites. By and large for any multi-site non-provider organization their internal networks need to be re-engineered entirely. They'll need to redesign their network (it's not just flip a switch, update some DNS records and change a few IP's) and with the changes to DHCP and the functional elimination of NAT support the redesigns become complex. Plus they likely have legacy hardware without IPv6 support running in various non-core uses which will need to get replaced (you'd be surprised how much old hardware soldiers on running internal stub networks or as local servers for support or admin groups, there's a lot of this in large organizations as it's often easier to just deploy retired hardware than to write a business case to get your regional support centre a shell server or similar). And frankly, IPv6 has architectural issues, especially with regards to IP allocation and DHCP. It's core design is at odds with standard practices today (NAT and portable IP space being the big stumbling blocks) and there's going to be a fair amount of speedbumps in rolling it out globally as large multi-site organizations run into issues, especially with their original IP allocation. IPv6 isn't broken by any means but it does change the rules in ways which will cause deployment problems. There's good reasons why the large providers have been avoiding deploying it for as long as possible and they come down to a lot more than just cost.

Put your Nose to the Grindstone! -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.

Working...