Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
For a home router, that would mostly be recursion, which is easy, install Unbound with auto-key and NTP, done. ;-)
On the authoritive side it has been much harder to get everything done, lots of automation and very strict checking is needed for key rollover.
Anyway, I think IPv6 is probably more important now. Still far to little provider networks have IPv6 deployed.
In 2012 IPv6 deployment will be inevitable, every network that does not do it will start to lose customers.
IPv6 on these little boxes in people's homes
Posted Dec 7, 2011 21:59 UTC (Wed) by tialaramex (subscriber, #21167)
The big step forward for 2011 over last decade is that several suppliers _tried_ to sell such things, but they all struggled to deliver something reliable enough and cheap enough to be acceptable to even a generous, technically competent and IPv6-enthused ISP, let alone the cut-price ISPs supplying most users.
Even if one of these (or another previously unknown) manufacturers actually gets the formula right in 2012, there's no way most home customers will have IPv6 capability from their CPE in 2012, it's too big a deployment task. After the "Cliff ahead, divert now" signs ran out and the engine went quiet, that wasn't because the danger was averted, it's because we went off the cliff. The next sound will be the crash as we hit the bottom. Strategies involving braking or turning the wheel to avert disaster are now irrelevant.
Posted Dec 7, 2011 22:04 UTC (Wed) by paravoid (subscriber, #32869)
Posted Dec 8, 2011 2:29 UTC (Thu) by tialaramex (subscriber, #21167)
The first is "Well, Cisco do it". Yes, and so do several other high-end switch/ router vendors. But they sell into the enterprise, where the guy installing the CPE knows what DHCP is and whether they want to enable NAT, not into homes where you need a diagram just to explain how to switch it on. Most importantly, they charge a LOT of money for these products.
The second is "This device requires you to plug it into an existing router". Ignoring for a moment the reality that this means you're not really doing native IPv6 but some kind of tunnelling (and so you will probably pay in terms of reliability and performance) it means an extra box per customer. That breaks the economics for the ISP. It's viable for a few fanatics, but it isn't a way to get millions of ordinary households
[ Digital broadcast TV is a useful comparison here. It was _possible_ to build boxes that turn a digital TV multiplex into an old-school PAL-encoded analogue signal to feed into a pre-SCART era television, and in fact such boxes were deployed where needed. But for the vast majority of people the digital TV upgrade happened when they purchased a new, better television which had the local DTV standard baked in ]
The only ISP in my country that actually has ordinary household IPv6 customers right now, so far as I can tell, has despaired about finding a way to deliver CPE without these tricks. Some of their customers can afford to buy an actual Cisco DSL device, and others are happy to burn custom firmware or run some unsupported beta, but to roll it out to the rest of their customers, as they'd like to do, they need a real solution, one that works, is properly supported, and is available (not "in beta") at non-luxury prices and they haven't found one. Right now (as-in, since November) they're experimenting with Technicolor, but this is only the latest in a series of experiments, and most of the previous ones were abandoned, because a manufacturer says "How hard can it be?" and promises to support a test rollout then they discover the answer is "Actually it's not as easy as we thought" and that's it. Hardware vendors are really bad at software.
Of course it will all fix itself somehow, just don't believe the people who say it's going to be painless.
Posted Dec 8, 2011 5:52 UTC (Thu) by mtaht (✭ supporter ✭, #11087)
I like to think we've identified a few more areas in IPv6 that need serious work.
Upselling to NAT
Posted Dec 8, 2011 18:59 UTC (Thu) by dmarti (subscriber, #11625)
As a big ISP, you could re-brand the change as an upgrade to "Family Friendly" or "High-Security Firewalled" service. Start out offering it as a paid upgrade, then make it "free for a limited time", then the default for new users. If it breaks some network service, just say that the other end doesn't like Families or Security.
This is so much easier than IPv6 that I don't see why the ISPs won't do this instead. (In Karachi, Pakistan, an ISP will sell you 100Mbps Ethernet to your neighbors, decent backhaul, and NAT for $8/mo. This works fine for Skype, Facebook, and YouTube.)
Posted Dec 8, 2011 22:13 UTC (Thu) by drag (subscriber, #31333)
They don't upsell, they just don't talk about it. They just do it. Then performance and reliability drops somewhat and irritates the people that depend on certain VPN software or VoIP for their work or whatever.
The problem ISPs now face is not enough public IPs for their customers, but not enough private IPs for their networks. When your a company like Comcast and you are forced to use multiple duplicate 10.0.0.0/8 networks you know you are running into some serious addressing limitations.
What we have going on right now is that ISPs are doing things like tunneling IPv4 over IPv4 in order to provide the network infrastructure necessary to deliver public addresses to customers. If you are going to give private addresses you are going to have to do some really crazy stuff like combination of tunning NAT connections some multiple NAT'd networks to get the TCP connections to customers. Tunneling IPv4 over IPv4 over Ipv4 type stuff.
On top of this NAT is not some sort of panacea that is going to buy you a lot of time.
The number of ports you have is limited to 16 bits minus whatever needs to be reserved. Each connection on a NAT router takes a port. So I'm guesstimating that leaves you about 30,000 useful TCP connections per public IP address. I am sure that things start to break down before that. Just doing a simple google about "linux" and clicking on a wikipedia link I get about 20 TCP connections started. So for every public facing IP address you can serve 1000-1500 active customers. And this is not really something you can ramp up for peak usage or anything.. it's a hard limit. Once customers start banging against connection number limits then things are going to suck for them.
What is going to happen, what I am guessing is happening is this:
ISPs are going to switch their networks entirely over to IPv6. They will be tunneling IPv4 over IPv6 to their customers. I expect that the larger ISPs are already well on their way. Once the roll out of the migration from IPv6 to IPv4 is complete then they will start fazing out support for DOCSIS 2.x modems and whatever the equivalent for DSL is. The newer 3.0 modems have IPv6 built in as a requirement for the protocol. Then they will require customers to purchase new routers. These things are probably going be pure IPv6 with a single IPv4 address mapped to it that tunnels over the IPv6 network.
'Computer Appliances' will start requiring IPv6 for various things. They won't really be advertising it as such they will just say things like ISP compatibility and DOCSIS requirements and such. It'll be a headache, but it will need to be done. They will require the higher performance that needs the newer level 1 protocols anyways. Blueray players, 'Smart' Televisions, IP-based cable boxes, PS3/XBox/etc, that sort of thing.
One thing that is important to keep in mind is that you don't really need IPv6 support on your 'home NAT router' to have IPv6 support in your appliances and in your OS. Any modern system can have full IPv6 internet access very easily on any "IPv4-only" NAT network. Full stack access. No firewalls, no port limitations, nothing. 100% unfiltered access right through any common NAT firewall. I think things like PS3 support this already. Microsoft already uses it for Windows 7.. it's requirement now for file sharing to work properly nowadays. Linux it's a bit more of a headache, but it's slowly catching up to Microsoft.
So it's not really necessary for customers to upgrade their home routers, but it will make things better.
While all this is happening it will slowly start to dawn on businesses in the USA that they will not be able to do business in certain parts of the world unless they have some sort of IPv6 connectivity support. Especially with China.
As IPv6 gradually moves to mainstream it will free up more and more IPv4 addresses to extend the useful life of that protocol.
Posted Dec 8, 2011 22:26 UTC (Thu) by dlang (✭ supporter ✭, #313)
actually, a connection is the set
source IP, source port, destination IP, destination port
so you can re-use the same source IP and source port if you have a different destination IP and/or destination port.
the OS doesn't re-use the source port by default, but it could. so there is really no long-term reason for the NAT boxes to run out of the ability to handle connections.
Posted Dec 9, 2011 16:39 UTC (Fri) by ncm (subscriber, #165)
Posted Dec 7, 2011 22:10 UTC (Wed) by dlang (✭ supporter ✭, #313)
I fully expect that additional layers of NAT and a market in IPv4 addresses is going to make the crash a lot softer than many people are predicting (and I think soft enough that most people won't notice it)
however, the existence of NAT is enough to qualify as a 'diaster' for many IPv6 advocates
Posted Dec 8, 2011 6:10 UTC (Thu) by mtaht (✭ supporter ✭, #11087)
Well said. The first generation of manufacturers that tried to produce 'IPv6 certified' gear tried to make their old kernels (usually 2.6.16 based) do it, on hardware designs and assumptions that were equally old, and failed.
The only solution to having gone off that cliff that jg and I could come up with was to try and prove that the modern kernel development process was the fastest and best way to swap out the wheels and engine, and install wings before we hit bottom.
Posted Dec 10, 2011 17:02 UTC (Sat) by ballombe (subscriber, #9523)
Posted Dec 8, 2011 5:47 UTC (Thu) by mtaht (✭ supporter ✭, #11087)
... and we'd already had it up and running for quite some time at that point.
however, what you write above strongly implies that you haven't tried to get DNSSEC to work right on cheap CPE. You see, DNSSEC requires not that time be accurate, but accurate to within an hour.
Cheap CPE does not come with a battery backed up clock. So you end up with this circular dependency on getting time, for which you need DNS. There are related failure modes where basically you DO want to be able to check if it's DNS failing or DNSSEC and do the right thing.
See bug 113.
Posted Dec 8, 2011 11:56 UTC (Thu) by Lennie (subscriber, #49641)
I just didn't know a cheap CPE did not have a battery.
Thanks for clearing that up.
Posted Dec 8, 2011 13:43 UTC (Thu) by job (guest, #670)
Posted Dec 8, 2011 14:53 UTC (Thu) by mtaht (✭ supporter ✭, #11087)
It cuts 10s of ms of latency off your provider's resolver for cached data.
It lets you have your own DNS for inside your home.
It lets you have trustworthy DNS data when your provider does not provide it - for example, playing with NXDOMAIN.
Posted Dec 8, 2011 19:33 UTC (Thu) by job (guest, #670)
Posted Dec 8, 2011 20:27 UTC (Thu) by mtaht (✭ supporter ✭, #11087)
Secondly, you still can (and should) use the upstream provider as a forwarder DNS, for example, comcast's DNSSEC servers are usually less than 10 ms away. But in the home, your DNS server is .02ms away.
Posted Dec 8, 2011 22:24 UTC (Thu) by Simetrical (guest, #53439)
Posted Dec 9, 2011 0:57 UTC (Fri) by zlynx (subscriber, #2285)
I'm going to blame NetworkManager for this Linux situation. It used to be pretty easy to modify the network scripts to always point DNS to localhost. NetworkManager seems it makes it far too difficult to configure a local DNS cache.
If you do figure that you need to add dns=dnsmasq to the configuration file, it turns out that dnsmasq is the only supported local cache, and then you find out that it couldn't possibly have been tested, as it crashes NetworkManager randomly (or possibly when two interfaces come up, or it might have something to do with VPNs, or maybe suspend/resume).
Really, the whole caching DNS is a lot easier to set up on the router.
Posted Dec 11, 2011 19:08 UTC (Sun) by niner (subscriber, #26151)
On the KDE Network Management Plasmoid I just edit the connection and change the Method from "Automatic (DHCP)" to "Automatic (DHCP) addresses only" and type the IP address of my DNS server into the DNS Servers field, hit OK and be done. I find this much simpler than with the configuration method I used before NetworkManager. And I can change this per connection so that at home I use my local DNS while at work I use whatever the DHCP server gives me.
Posted Dec 12, 2011 3:35 UTC (Mon) by zlynx (subscriber, #2285)
Posted Dec 8, 2011 20:53 UTC (Thu) by zlynx (subscriber, #2285)
I used to run my home network router on a dual Pentium 166. It did routing with IPv6 tunnels and QoS, Squid, DHCP, web server and BitTorrent.
It worked very well. The CPU in modern home routers (well, above the $60 level anyway) is much faster than that P166 was, so I expect it will do an even better job.
Posted Dec 8, 2011 22:08 UTC (Thu) by dlang (✭ supporter ✭, #313)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds