Some of this traffic was attributed to the tragic death of Robin Williams - RIP.
On Tuesday, 12 August, 2014, the internet hit an arbitrary limit of more than 512,000 routes. This 512K route limit is something we have known about for some time. The fix for Cisco devices – and possibly others – is fairly straightforward. Internet service providers and businesses around the world chose not to address this …
"One thing I do know is that it is the job of network administrators to know about these issues and deal with them. "
I would say the hardware vendors and the folks who set the standards should be lined up against the wall before the admins. If there is a 512K limit then it should be made into a circular list. As new usage routes come online, the ones that have not been used the longest get dropped. Keeping a list of dead router paths serves no purpose and is the real flaw in the system.
As I understand it, this isn't a traffic issue, it's about the number of routes that a Border Gateway Protocol device must keep in its routing tables. There are now more than 512K routes, i.e. links between Autonomous Systems, on the Internet, breaching another one of those arbitrary limits which someone set *ridiculously, humungously huge* way back when your operating system ran from a 5.25" floppy disk.
If device operators are lucky, then increasing the routing table size is just a configuration issue (for values of 'just' involving taking down your network), otherwise they may have actually to replace the physical devices.
My mother actually told a new Electronics Officer that the reason the radar display wasn't working was that all the green electrons had leaked out and she had to put some more back in. Naturally when he passed this didn't go over very well for him when he reported this to the base commander in the presence of his boss, the Operations Officer.
"For years I've been glibly saying "the internet is full" as a reason for random outages, or why I can't field a call at a given moment."
For years I've been saying "the internet is like Bangladesh - every now and then bits of it wash away for no reason" to explain random outages.
We talk about cyberspace as though it was real, and forget that to get from point A to point B, information has to pass through real space, carried on signals that are governed by real physical limits, going through real routers and gateways, with real practical limits on bandwidth.
There are technological ways to increase information transfer throughput. But they all cost money, And they are all subject to the same laws of mathematics and nature. Imagine what this is going to look like jf governments and special interests get their stuff together and figure out a way to control and charge consumers for access to bandwidth.
Unfortunately the same sort of people who designed the defunct mess that was OSI designed the complex mess that is IPv6.
If IPv6 had been designed by engineers (rather than by theoreticians) it would have been much less complex - just increase the size of the addressing field by 2 bytes and map all existing IPv4 public addresses to IPv6 with the 2 additional address bytes being zero. Give each country its own unique 2 byte address prefix for additional connections once the IPv4 range is used up then additional values for large countries when their first prefix is near full. If this had been done then IPv6 would be in widespread use by now. (6 bytes of addressing allows for over 280 trillion addresses - over 20,000 for every man, woman and child on the planet.)
IPv6 looks to me like a slow-motion car crash. I'm no network techie, in fact although I speak geek fluently enough to order dinner or a hotel, my only possible claim to techie-dom is water systems design.
But for years now, I keep reading stories about how we're all going to have to go IPv6 RIGHT ABOUT NOW!!!! Well, it's usually in a couple of months' time - becuase someone's just found another block of v4 addresses down the back of the sofa.
And then I read about what it can't do. Because apparently NAT smells of poo. And everything must be connected to everyone else. I wasn't aware that it would bugger up backup network connections for example.
It's a bit like reading about the Euro crisis, for which I have enough economics to understand. A high priesthood have ordained a thing. And so it shall be done. But it can't be done. Oh, but it will be done [cue sinister voice]... It's all going to go wrong. No it isn't. Look guys, this isn't the ideal world where academics and dreamers live. This is the real world, where people fuck up, penny-pinch, cheat, or steal. It's all going to go horribly wrong.
The only difference is the Euro-fanatics managed to just get over the line, and get their dream built before they ran out of political momentum. Just in time for it to slowly turn into a nightmare. Whereas IPv6 seems to be stuck forever in limbo.
It makes my brain hurt. I hope all the plug and pray stuff works properly, if it ever does come in. Because I have enough trouble with home/small office IPv4 networks - and I'm never going to remember one of those huge IPv6 addresses.
The real problem is that IPv6 goes far beyond fixing the limitation of 32-bit IP addresses.
If tasked with solving the problem I would have simply added more bytes on the left to extend global addresses and on the right to allow more local (but globally accessible) addresses.
Of course that was far too simple but, more importantly, doesn't provide a gravy train to ride.
How exactly does one ride a gravy train, without drowning in brown liquid?
Well you can sit in or on the next carriage behind. If you can fit, of course.
Manor house near me has tracks for its gravy train that goes into the walls courtesy of the eccentric Victorian fellow who built it and the elderly neighbour, when she was a small child and living there, used to climb aboard.
As mentioned above, the problem to be fixed (not enough addresses) is - at least conceptually - trivial to fix: add a bit more to the address length.
This is exactly what happened in Australia (at least in Sydney and Melbourne) when the 7-digit phone numbers were not enough: they added another number. At the start, all the existing numbers just had a '9' prepended. As new numbers were needed, they started them with '8' - instant doubling of available numbers with as little pain as possible.
Of course, this has happened in most countries and the numbers have steadily increased in size with the population. BUT, it has been done methodically and - in most cases - very sensibly and with an eye to causing as little disruption as possible.
Whoever was responsible for IPv6 saw it as a chance to fix everything they believed to be wrong with IPv4 and to implement what is (in their view) a perfect system.
IPv4 has a glaring problem, which is the impending exhaustion of addresses. It almost feels like we are being held to ransom - we can't get a fix for the IPv4 address problem unless we agree to replace a working system with some committee's idea of a perfect system.
"simply added more bytes on the left"
Yet again I have to point out that this "simple" change would make all un-updated systems incompatible with all the new ones with bigger addresses, and therefore *all* the tricky problems of v4/v6 coexistence that we have been dealing with would have occurred just the same (dual stacks, tunnels, NAT64,...).
Also - contrary to the article, multihoming IPv6 sites without NAT is not a problem:
It's really time to stop bitching about IPv6 being different and just run it, already.
Your solution is exactly the one I griped about. It is absolutely reliant on DNS to function correctly, and requires tossing out any application that can't handle on the fly readdressing or multiple IPs. You either end up facing a single point of failure in DNS or significant expense redoing virtually every single fucking application on your network.
Worse than that, your solution isn't just regular "preserve end-to-end at all costs", you're touting DHCPv6 as the means to salvation here too! Unbelievable!
Maybe what you've got there will work, once every single device out there supports IPv6 in a manner that complies with the RFCs in question. AND when we've all abandoned our millions of dollars worth of investment in existing applications and recoded everything to suit the New Black.
But, being honest now, when are you expecting that to occur? How many days/weeks/months/years/decades from now will we be at the point that there are no more non-compliant devices and no legacy applications that can't deal with your preferred solution for multihoming?
In addition to the above, please detail for me exactly how your proposed solution provides superior value for dollar and return on investment versus deploying Network Prefix Translation, bearing in mind that - as a business owner - I please the value of the ideological purity of the end to end model at exactly $0.
Size your solution to the 80% of businesses on the planet: 50 to 250 users. Work in that for the next 20 years these companies will be running workloads on site that they will want to host to the rest of the world in a redundant fashion. Assume that these companies are not American, so they won't be using ISPs that will allow BGP on SMB accounts, and they won't be comfortable using the public cloud for everything.
So go ahead and bottom line it for me. Where is the business case for the solution you propose? And - in dollars and cents - show me how it will benefit me versus Network Prefix Transation? Make your case well enough and I'll publish it with commentary as an article.
Otherwise, you're just a bag of hot air, espousing dogma and presenting no real-world solutions.
"It is absolutely reliant on DNS to function correctly"
Yep. As are most other correctly configured IP networking type things.
"requires tossing out any application that can't handle on the fly readdressing or multiple IPs"
You mean 'that has been bodged to use IP addresses instead of DNS names as good practice would dictate'.
"DHCPv6 as the means to salvation here too! Unbelievable!"
Sensible. Everyone and their dog uses DHCP. If you are moving to IPv6 then DHCP gets upgraded too.
"Maybe what you've got there will work, once every single device out there supports IPv6 in a manner that complies with the RFCs in question"
It does work. Companies like Colt have already fully deployed IPv6 on their core networks. And there are a number of ways of supporting devices that don't work with IPv6. Just because you don't understand the details, doesn't mean that others are so limited.
"But, being honest now, when are you expecting that to occur?"
It has already started. For the majority of uses the curve is not going to start to rise steeply for a few years yet, but it will...
"In addition to the above, please detail for me exactly how your proposed solution provides superior value for dollar and return on investment "
More addressing capacity and enhanced capabilities for less maintenance effort.
"so they won't be using ISPs that will allow BGP on SMB accounts"
That will change as IP6 hits mainstream.
"Where is the business case for the solution you propose"
That the existing solution is out of capacity and that will become a rapidly increasing problem unless we do something about it.
"I'll publish it with commentary as an article."
Oh god help us. Why not read such an article from people who actually understand the subject? See blogs.cisco.com/enterprise/why-would-anyone-need-an-ipv6-to-ipv6-network-prefix-translator/
"you're just a bag of hot air, espousing dogma and presenting no real-world solutions"
Pot - meet kettle.
So all you have to offer is dogma, religious belief and assertions. No actual functioning solutions, no value for dollar and no hard timelines. You won't even put your name to your claptrap so we can hodl you to the wishy-washy tripe you shovel.
You really are an internet hippy. Get off my goddamned lawn and don't come back until you've cut your hair and have something of value to offer.
What's even more hilarious is that the blog you link to has the individual being interviewed agreeing with me. Network Prefix Translation is the solution that will see us through. If other solutions become universally viable, then and only then will we look at transitioning wholesale. But block-shifting from IPv4 NAT-PT to IPv6 Dogma edition is fucking batshit insane.
"You mean 'that has been bodged to use IP addresses instead of DNS names as good practice would dictate'." -> this completely misunderstands the problem. Most applications do a DNS lookup the first time they encounter a network name and keep that address in memory.
However your high-availability solution appears to change network addresses on the fly. Your application would need to do a DNS loopup every time they communicated with the outside world. Sucky.
But more importantly, I quite like NAT, simply to keep my internal devices out of view of the great unwashed. It forms the first line of security, followed by basic system hardening and antivirus tools.
In Microsoft Windows operating systems, IPv4 addresses are valid location identifiers in Uniform Naming Convention (UNC) path names. However, the colon is an illegal character in a UNC path name. Thus, the use of IPv6 addresses is also illegal in UNC names. For this reason, Microsoft implemented a transcription algorithm to represent an IPv6 address in the form of a domain name that can be used in UNC paths. For this purpose, Microsoft registered and reserved the second-level domain ipv6-literal.net on the Internet. IPv6 addresses are transcribed as a hostname or subdomain name within this name space, in the following fashion:
is written as
This notation is automatically resolved by Microsoft software without any queries to DNS name servers. If the IPv6 address contains a zone index, it is appended to the address portion after an 's' character:
OK, i've just stared looking at that link, and right at the top I see a red flag already:
"However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity."
Errm, while the USER may want transparent end-to-end connectivity, the network engineer/admin may not want NETWORK level end-to-end connectivity. They may WANT to introduce things like proxy servers, which right there break your transparent end-to-end connectivity. Or how about (as my organisation does) an SSL interceptor that basically does a man-in-the-middle attack on all SSL sessions (with the exception of whitelisted known trusted sites, e.g. banks) to virus scan the stream?
From my reading so far, it looks fairly complicated and would require someone with at least reasonable computer/network knowledge and skills. To set up multi-homed NAT IPv4? Simple, buy dual port router, hook one port to ISP one, hook second port to ISP two, enter ISPs authentication (e.g. if its xDSL), setup complete. Multi-homed failover (or even load balancing if the appropriate check-box is ticked) and you are done.
I don't want end-to-end connectivity. NAT means I don't need to worry about the security of my network printer for example. Anyone on the LAN can print to it without needing a password or anything like that. That's OK, because I control who is allowed on my LAN. I don't want the whole world to be able to print to it, because it is a feature that spammers would love.
The original point of the /bits notation was to steal bits from the source and destination port addresses when this problem 1st showed up in IPv4 space in 1991. So an address like 220.127.116.11/34 would use two bits from the source and destination port so from a core routing point of view, a web server might be on 18.104.22.168:80 and 22.214.171.124:32848 (0x8050=32k+80). The only software that needed changed would be the network addressing libraries (aka libresolve) and some edge routers (aka NAT). We had this working on an AGS+ in 1991 without any major changes to applications other than a bind library and a wrapper about a winsock function. The idea was to treat all routes as /24 starting then with long term migration to /32 so everyone could dual home with their own IP addresses. AT&T even built a router that could cope with 16 million routes in 1992.
Biting the hand that feeds IT © 1998–2019