Slashdot Mirror
The IPv4 Internet Hiccups
New submitter pla writes: Due to a new set of routes published yesterday, the internet has effectively undergone a schism. All routers with a TCAM allocation of 512k (or less), in particular Cisco Catalyst 6500 and 7600's, have started randomly forgetting portions of the internet. 'Cisco also warned its customers in May that this BGP problem was coming and that, in particular, a number of routers and networking products would be affected. There are workarounds, and, of course the equipment could have been replaced. But, in all too many cases this was not done. ... Unfortunately, we can expect more hiccups on the Internet as ISPs continue to deal with the BGP problem." Is it time to switch to all IPv6 yet?
Surely 512k ought to be enough for any router?
We changed all our systems over time to handle this great IPv6 change, and haven't used IPv6 yet. Our service provider doesn't even offer it. Come on, some of us are more than ready. We will probably have failures, because it hasn't been truly tested, but we are far more ready than we were for Y2K.
Well, if you pay for the cost, otherwise it will be much easier to just patch the problems and keep on going.
That way we will have access to more mature technology when we do make the switch. Also, it is unfeasible to switch it all at once.
Gradual switching when needed is preferable.
There's still plenty of time to postpone that. Not until the last /2 is sold will I start to worry. And can't we start using a few 127.x.x.x? Do we really need 16 million addresses for testing?
/sarcasm
Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
just to avoid problems like this.
We seem to have a bunch of things failing somewhat on the same day... is Cisco effectively saying "We're taking back what you have... please pay more!"?
You're right. It was time 10 years ago. Now it's way PAST time.
SJW's don't eliminate discrimination. They just expropriate it for themselves.
This isn't really to do with BGP or IPv4 as such, it's an inherent problem in the way "The Internet" regards addresses.
You might be able to get some efficiencies in IPv6 by incorporating formerly-unrelated address allocations under a single prefix. But that doesn't solve the problem of a continuously growing network, increasingly complex (and commercially controversial) peering arrangements, the fact that IPv6 addresses are actually larger and the fact that you're going to have to support IPv4 anyway in parallel with any IPv6 transition (I don't personally believe it will ever happen, but that's a different story).
You could, however, get rather more efficiency in core routing tables if network addresses only had a very transient existence and were related to the source/destination route to be employed (eg: look up a domain name, do some route pre-computation, allocate some addressing tokens that make sense to the routers on the path, recalculate the route periodically or in response to packet loss). That's not IPv6, though. IPv6 has the same order of dependence on every router knowing about every destination network as IPv4 does (give or take the slightly greater prefixing efficiency).
TL;DR - The Internet is getting bigger. Buy more kit.
googling verizon, comcast, and time warner it seems like their original pledge in 2012 to start rolling out ipv6 has quietly halted. most of their sites simply say "check back" while others imply certain undisclosed service areas may be exposed to both 4 and 6. forums are another story, with most customers and techs confirming the support exists, but either modems arent enabled to receive ipv6 due to bugs, or the support is broken in all-in-one devices in the case of DSL.
speaking from a linux neckbeard standpoint, i dont care. ive had competent functional v6 support for almost a decade and in many cases implemented it for pay. In my experience the problems associated with implementing v6 are related to companies angry about any downtime at all, or vendor specific appliances that just cant for some reason or another. they either lied about their ipv6 support, only partially support routing IPv6, or have egregious bugs in their implementation that cause stability problems in the rest of the network. Hosting providers have done an excellent job of supporting it from what ive seen, and most (with the exception of godaddy) are very generous in their IP offerings (i get 30 with ramnode.)
Good people go to bed earlier.
You have no idea what you are talking about. Two words: prefix aggregation.
Probably why I couldn't reach NeoGAF for most of yesterday, unless I went through tor. Which I did, because I'm a man and I have my needs.
Belief is the currency of delusion.
Yeah, I think 127.x.x.x would be good for temporary IPv6 mappings.
This is a real question: Do you know what IPv6 does instead of BGP? Because as far as I know, IPv6 is still using BGP, and that is what this is a problem with. In fact I can only see IPv6 making things worse in that regard because tons more address space means that more AS assignments would be easy to do.
So if it really does offer a solution, please enlighten me I'd be very interested. If this is just an example of trying to use a problem to push a favoured agenda, then please knock it off.
Isnt subnetting more a software implementation DHCP, and BGP thing in the router, enter a net mask address and network address into the router config and then the router can analyse the addresses to determine if they are local or not. It seems, if IPV6 does not provide an equivalent for DHCP's getting the net mask then we are screwed. But net masks are not something you find in the IP packets headers themselves.
Except that this has nothing to do with IPv6. IPv6 will do nothing to resolve this problem and will in fact make it worse because the problem itself is due to a router not having enough RAM and nothing about IPv6 results in less RAM usage.
Sure, we should get on the IPv6 bandwagon, well, except it sucks right now and can lead to some annoying connectivity issues when sites are misconfigured, or setup IPv6 and then forget about it so you're trying to connect to an IPv6 address thats no longer used because no one bothered to update DNS ... or their IPv6 connection is through one of their shitty over saturated links.
My ISP does IPv6, as does all my equipment. I had to disable it so that the rest of my family doesn't wonder why random sites don't work on their PC but work fine on their phone and while I can't remember the ones off to the top of my head, there are some big ones that regularly fuck up. Hell, even Google's IPv6 connectivity is shoddy at times.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Why would that be different than with IPv4? Prefix aggregation, AKA route summary, AKA Supernetting, has been available for a very long time. Unless IPv6 addresses are being handed out in a way that's much more conducive to this, it won't really change anything. This guy agrees (#4)
Further, since IPv6 is a longer address, fewer can be stored. Per Cisco, the Catalyst 6500 can handle 1M IPv4 addresses, OR 512K IPv6 addresses (but not both simultaneously)
(Yes, I know the Catalyst is a switch, not a router, and the summary is bollocks for confusing the two. It was, however, the first mention of it I found)
First of all, paragraphs are your friend.
Second of all, the solution you described already exists.
https://en.wikipedia.org/wiki/...
On that same page, there are a bunch of other solutions as well, this has already been thought of :)
Yup, unless some sort of usable interoperability between IPv6 and IPv4 is thought up and rolled out, the transition will take a very long time. In fact, it might never even happen, and we'll just end up with two separate Internets!
The problem as stated is that IPv6 is NOT an upgrade to IPv4. Saying that it is would be like saying Windows is an upgrade for Solaris, or Linux is an upgrade for VMS. They are completely different things with no commonality at all.
This transition will be no different than moving from IPv4 to IPX/SPX or from Windows to VMS - You can't keep *anything* from IPv4, everything has to go.
The problem is, there is too much embedded infrastructure to just rip out all the old stuff and replace it, and a lot of old things don't have an IPv6-capable replacement.
This is the gigantic elephant in the room that is still being ignored, and until it is dealt with, people can harp on about address exhaustion as much as they like, but this transition will not happen; You will just have two incompatible networks running side by side.
Unless IPv6 addresses are being handed out in a way that's much more conducive to this, it won't really change anything
Which they are, as a direct result of v6 being so huge. See RFCs 1715 and 3194 for discussion on this.
Obviously in the long run we'll end up with a higher absolute count of routes in v6 (because supporting more people was the other reason for it) but the route count will scale far better than a network that has to be run at a ridiculously high HD-ratio because it's too small.
One of the design goals of IPv6 was to reduce the size of the global routing table. That's why there are so many more addresses in IPv6 than there are ever going to be devices. Each provider gets so much address space that nobody needs to come back for more. That means there's no address space fragmentation due to address scarcity, like there is with IPv4, where providers usually have dozens or hundreds of separate allocations which can't be aggregated and must all be entered into the global routing table. IPv6 addresses are four times as long as IPv4 addresses, but there are far more than four times as many routing table entries per ASN with IPv4 than with IPv6
It's Betteridge's Law of Headlines and it doesn't apply: The question isn't in the headline.
To some degree obviously, there is a lack of incentives for ISPs to change - if they still have enough addresses for themselves, then switching to IPv6 is only costs, not benefits.
Maybe some of the larger sites, like youtube, facebook, wikipedia should have a meeting to discuss the switch-over and then start shaping IPv4 traffic - just reduce capacity on IPv4 by 5% every month and see how long it will be, before ISPs will lose customers if they DON'T switch to IPv6...
Why would that be different than with IPv4? Prefix aggregation, AKA route summary, AKA Supernetting, has been available for a very long time. Unless IPv6 addresses are being handed out in a way that's much more conducive to this, it won't really change anything. This guy agrees (#4)
He is kinda correct, but the RIR's have come up with addressing plans to deal with this.
/29 minimum. This is 2^35 networks (assuming you are using a /64 per network as recommended). If you prove you need more than a /29, fine, you can have it.
/29? Fine, increase your subnet mask to /28 and carry on. This doubles you address space. Carry on until you are at a /26. That is a LOT of room for growth.
My info comes from the RIPE region, as its the region I'm in.
Every ISP gets assigned a
The next 3 bits are then reserved for future use. You use up your initial
In the IPv4 world this isn't possible. You get your allocation. You run out. You get another etc. Verizon are currently announcing 1,446 IPv4 prefixes from AS701, compared to the 12 IPv6 prefixes. Of the 12 IPv6 prefixes 5 of them are the one prefix they have deaggagated, the rest are customers with PI space.
You have a point about the near term, but long term once IPv4 has died a death (10+ years) the routing table will shrink again.
v6 makes things better, because it uses 128-bit addresses rather than 32-bit addresses. See RFCs 1715 and 3194 for the details.
Yes, there's a small linear factor of extra memory required for v6 routes vs v4 routes, but that's irrelevant compared to the route count reduction that comes from a lower HD ratio.
Can't figure out if you were going Insightful or Funny.
Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
No transition period? We are about fifteen years into that transition period, and it has sucked immensely with things like the requirement of man in the middle stuff like Skype just to get VoIP to work on an internet infested with NAT.
Also routing only occurs on the first 64-bits of an IPv6 address, the router doesn't need to store the host last 64-bits of an IPv6 address.
In the early days IPv4 addresses were handed out in a way that kept routing tables simple, but some time about 10 or 15 years ago we started to run out of blocks that were in the right range, so started allocating them all over the place. It will take us several lifetimes to get to that stage with IPv6.
In addition to the other points brought up by other posters. Routing decisions occur only on the first 64 bits of an IPv6 address. There is no need to store the entire address.
Core routers only use the first 48bits as that's the smallest block that is routable on the Internet. Which is why IPv4's /24 vs IPv6's /48 explains the routers supporting 1024K IPv4 routes or 512K IPv6 routes or a 512K/256K split. Exactly 2x difference. But IPv6 has sparse allocations resulting in about an effective 10x reduction in the number of routes.
I have no idea where you got that information. Check http://www.tcpipguide.com/free...
This particular problem is due to the way routing on the Internet works, where generally every router must hold routes for every prefix announced on the Internet. That system doesn't change with IPv6. Now, there might be fewer IPv6 prefixes at this time than IPv4, but intrinsically there's nothing about IPv6 that addresses the problem that all prefixes must have global visibility.
To fix this kind of problem requires changing how routing is done.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
That doesn't solve the problem, it mitigates ONE aspect of the problem.
It will effect large ISPs with large numbers of IPs, which are few and far between.
It does nothing to resolve the actual problem of router table growth which is caused by the number of networks, multihoming and address portability.
Multihoming and address portability make what you've said irrelevant, and thats where the growth comes from.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Theoritically, any block of Ipv4 addresses outside of the local subnet could be used, if an ipv4 address is used as a fake address, and then the user asks DNS address which happens to resolve to a real IPv4 address with the same number, then, the same NAT trick could be used with a mapping between created between another temporary local ipv4 address to the real internet ipv4 address which was already being used locally as a fake ipv4 number. Though, I would only recommend that be used as a fallback if 127.x.x.x is used up. A small part of the of RFC 1918 addreses could also be allocated for the pool of fake ipv4 address, such as maybe 172.20 and 172.21, giving a pool of 131072 ipv4 addresses, plenty for most use cases. I doubt most people will have that many TCP connections at once. Since 127 is not used for local networks, it is the best choice however as the first choice. Again, 127 is so large, i doubt most users would ever exhaust it, especially if the fake ipv4 mappings are timed out after a period of maybe 1 -7 days or so.
There's no good reason to think there'll be a significant improvement in HD with IPv6, or significantly fewer prefixes advertised.
The issue is orthogonal to IPv6, it's fundamentally about how Internet routing is organised today. No hierarchy, and all prefixes must have global visibility. Hierarchical routing of the 90s has a bit of a bad name, and support for aggregation in BGP has been deprecated. However, there are things like topographical-landmark routing, which improve on the deficiencies of hierarchical routing. These would allow the Internet to grow without routing tables everywhere having to grow in direct proportion. Instead, routing tables wouldn't grow much at all, even as the Internet grew, in relative terms.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
but that's irrelevant compared to the route count reduction that comes from a lower HD ratio.
Only if you assume you can reduce routes because there are so many people with diverse blocks in their network, which isn't the case so much.
The route count is much more a result of multihoming and portable address space, which means larger prefixes aren't going to help at all. At no point in my career would my provider having a larger prefix helped reduce the routing table as I have always had either portable address space, which is a direct allocation from a NIC rather than an ISP, or been multi homed which means at best I get the addresses from ONE of the peers and announce it out to another peer, but in that case traffic gets all screwed up if the upstream provider which allocated me the non-portable space aggregates it since aggregated addresses aren't preferred over non-aggregated address space.
I.E. larger upstream prefixes don't really help at all.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
The Mayans had predicted that we would run out of IPv4 addresses in 2012 -- and they were right.
I'll see your senator, and I'll raise you two judges.
With SDN, an infinite number of prefixes can be stored on the SDN controller, and the Internet router only needs to load prefixes into the router TCAM when there is actually a flow needed for that prefix.
We lost probably $30k in lost sales, and employees unable to do their jobs yesterday. Liquid web is going to lose a ton of customers over this. I don't know if it was their "fault," or if it was the top tier providers in their area they contract with. But as I understand it, if we had been with anyone really big who had us colocated in facilities way far away from each other, this would have been extremely unlikely.
Can anyone tell me how to set my sig on Slashdot?
You can talk all you want about what should and shouldn't be irrelevant, but at the end of the day the IPv6 routing tables take up less space in memory. Maybe you haven't noticed because you're too busy disabling things,blaming configuration problems on the underlying protocol.
Until there is sufficient IPv6 penetration that continuing to run IPv4 becomes pointless. If you turn on IPv6 on home networks over half the incoming traffic will be IPv6 traffic. Globally IPv6 is 4-6% IP traffic depending upon where you measure it. IP has replaced many networking protocols in the past. IPv6 will replace IPv4. The writing is already on the wall.
Many networks today are IPv6 only internally with protocol translation to talk to the legacy IPv4 Internet.
Other are dual stack translated to IPv6 only then translated back to dual stack on the Internet.
With IPv4 you are only going to get less and less functionality now that many ISP's are getting to the stage of having to deploy CGNAT. As a home user having a publicly reachable address will become a thing of the past.
If they can't hear/speak IPv6, then the Internet is going to feel like a very big empty room. Everyone needs to change to the new protocol. Everywhere. And IPv4 still has to work. Everywhere.
It's TCAM, not RAM, which is A LOT faster than RAM. That's why it's a problem that it's over 512k. Most routers have more than 0.5MB of RAM.
Was there a 10 year warranty on that? Seems like to fail all at once now is a sign of something intentionally wrong.
My solution is the one that would actually allow ISPs to gradually upgrade things over time rther than to replace everything at once, by allowing the interoperation. Its a lot easier if the changes are concentrated at the ISP end rather than effect subscribers as well. Its true that over time as due to the turnover of ipv4 older routers, that ISPs could gradually replace the subcribers routers with newer models. It would also be possible even for ISPs to collect older routers, flash them with new firmware, and put them back out, in the process of customer turnover cancellations and signups. The whole point is the solution i describe gives ISPs a transitiion period.
Given the time between IPv6 design and the eventual global adoption of it and abandonment of IPv4, will the broader adoption of IPv6 reveal problems addressed in a future revision?
I'll admit to being willfully ignorant of IPv6 other than seeing it as enormously more complicated than IPv4, trying to solve too many problems at once. I sometimes wonder if maybe IPv6 didn't appear so complicated and different that adoption might have been increased.
Couldn't they just have added a couple of extra bytes to IPv4 to come up with something that worked like IPv4? I also wonder about an addressing scheme like IPX, where a single network address covers an entire broadcast domain and node addresses are MAC addresses plus the network address. IPX network addresses were only 8 bytes, maybe that wouldn't be future proof enough (4.2 billion networks). I'm not talking about IPX as a protocol, just the system for addressing.
The advantage is relative simplicity (no need for DHCP, network addresses are discovered and the rest is built-in), broadcast domains can scale arbitrarily large without needing to renumber -- sure you can start out every network with a /16, but often they don't and there are complications in organizations just arbitrarily shifting masks past /24, such as running into other networks in the local routing domain.
Since node addresses are locally determined, ISPs would need to only assign a network address which would allow for basically unlimited public network addresses to each subscriber.
I actually bought a new router within the last year. A "nice" Buffalo model with DD-WRT built in. Only to find out DD-WRT doesn't support native IPv6 (which my old, faulty NetGear did, go figure). They just support Toredo or other tunneled IPv6 solutions.
Man, was I disappointed.
Maxim: People cannot follow directions.
Increases in truth directly with the length of time spent explaining them
Not the fact that wifi routers degrade, you are totally right about that, but that people will replace them. I'm amazed at how shitty someone's Internet can be and they have an "Oh well, whatever," attitude about it.
A good example near and dear to me is my parents. They moved in to their current place about 7 years ago and got a cheapass Linksys router to handle their NAT and WiFi. It has been giving them enough grief for me to hear about it for at least 3 years. They are not poor, a new router is not a big deal, yet they didn't get one. So I got tired of it, and also had an easy solution: When they were visiting me this June I upgraded my WAP to a new 802.11ac one and gave them my old one, which was working great.
They still haven't installed it. It's not like they don't have time, mom is retired and dad is semi-retired, it's not like it is hard, it is much simpler to set up than their old model and they can always call me. They just haven't bothered. Their router acts up, they go reset it, and don't bother to replace it.
Another somewhat related example would be a friend of mine. He's a young guy, under 30, and quite technically savvy. He's complained to me that the Internet at his house is not meeting advertised speeds, going quite well below it. Strange, since we are both on the same ISP, and live only a couple miles from each other and my experience has been that they always are right around max. I inquire a bit more and find out he still has a DOCSIS 2 modem. Ahh ok, well that is probably the issue. Though his connection is of a speed that a single DOCSIS channel can handle (25mbps), that modem has one one channel to choose from and it could well be too loaded down by other people on the segment. So my recommendation was to get a DOCSIS 3 modem. An 8x4 modem that is compatible can be had for like $80. That should solve any speed issues since now there's a bunch of channels to choose from, and will be compatible when they bump the speeds in the future.
He didn't want to spend the money, and so just complains occasionally about the speed.
For whatever reason, there are more than a few people who will just use old, failing, technology and bitch about it rather than fix the issue.
So the "compressed IPv6 address" has the low order bits used to reflect an IPv4 address. But I thought the low order bits were going to be MAC address bits in IPv6? The two seem inconsistent.
OK, I've done BGP before, and I've never heard of anything smaller than a /24 being globally advertised -- most common router configurations won't even accept anything smaller.
That said, how is any network of any size supposed to protect itself again ISP outages other than multihoming? It clutters the routing table, but there is no other solution.
"Is it time to switch to all IPv6 yet?"
No.
Sure. When most people will have adopted IPv6, we'll have a lot more IPv4 available!
Slashdot, fix the reply notifications... You won't get away with it...
I have no experience whatsoever with ipv6, but try to google "ipv6 ipv4 interoperability" and you will find lots of info about it.
This isn't a reason for migrating to IPv6 (although new routers with more TCAM - Ternary Content Addressable Memory) would also likely make implementing IPv6 easier.
The problem is the large number of networks that are being advertised, coupled with the number of locations that want a full BGP feed because their networks are multiply homed. Migrating to IPv6 will allow some reduction of network tables - if only because organizations with a single location that currently have multiple IPv4 networks can be allocated a single IPv6 network (and that might have a knock-on effect for organizations that are multiply homed.) It will work with organizations that are willing to tie themselves to a single ISP.
(Yes, I know that IPv6 builds in automatic address provisioning, intended to make deployment easier - but I still think that renumbering your network will be enough of a problem that there will continue to be ISP lock-in enough to encourage large organizations to get their own network numbers outside of an ISP's range.)
No. When Facebook goes offline, it will be the end of the world; and I love happy endings!
Life is not for the lazy.
Except people can, have and will deaggregate IPv6 space to do Traffic Engineering.
So the roads are twice as dangerous now as they were before the introduction of the motor vehicle. And no doubt it would be even worse if children didn't find ways to entertain themselves indoors because the streets are not as safe as they used to be.
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
I noticed no one had mentioned LISP. I don't completely understand it, but I'll add my two cents anyway.
LISP is supposed to help with routing table exaustion and keep the global routing tables lean. It does this with a distributed database to basically map out endpoints and create tunnels around the internet. This is so no one router on the internet needs to have a full table.
In the short term for backwards compatibility, endpoints will be identified with IPv4 or IPv6 addresses, but it seems to work with any unique ID, like a serial number or GPS coordinate.
Locator/Identifier Separation Protocol (LISP)
My additional two cents...
I realize I'm risking any credibility I might have by mentioning anything related to bitcoin, but I think it's an interesting idea worth stating. Although I don't have any interest in using bitcoins as a currency, I think the underlying technology is interesting and could be useful in other applications.
The idea is for organisations to "mine" for their IPv6 allocation. They can then use their "wallet" to sign their BGP advertisements so that their peers can be certain (for various values of certain) they own that prefix. This also has the effect of decentralizing the allocation of resources, and considering the vastness of the address space of IPv6, it would be a waste of time for anyone to attempt to mine all of it and hoard it.
Really, even if you are completely ignorant about it, it does not take much more than a short reading to see how simpler IPv6 is. That's why it corrects so many issues.
The problem with IPX style local names assignment is in security. Doing it in the open, wild Internet is a certain way to destroy it. The nearest option that's actualy usable is dynamic DNS, and it's quite widspread.
Rethinking email
The fact is, TCP v6 was defective by design, because of what it does not have, and that is a mechanism for a long transition period between ipv4 and ipv6. If we had such transition period, ipv6 would now be widespread. The transition period means that ipv4 and ipv6 networks can communicate with each other.
It's 2014 ... can we all just take a breath and realize there is simply NO solution to the pigeonhole problem that does not resemble CGN?
The only operationally viable solution for IPv6 deployment in a production environment (e.g. solution with minimal breakage) is dual stack with IPv4 CGN as needed.
The more complex but entirely doable part is ipv4->ipv6. Since ipv6 is larger address space than ipv4, ipv4 cannot directly see a lot of ipv6 addresses. The answer lies in the DNS system. When a user on an ipv4 network askes for the IP address associated with a DNS address which only has an ipv6 address associated with it, somewhere upstream, an upstream router and DNS server will conspire to 1) give the user (ipv4 peer) a fake IPv4 address for a DNS address 2) give the information on the ipv6 to fake ipv4 mapping to the router 3) which the router uses NAT to rewrite the packets headed out from from the fake ipv4 destination address to the real ipv6 destination address.
While your deploying NAT-PT and fielding calls from angry customers burned by IP literals embedded in web sites and protocols your competitors are just deploying IPv6 dual stack and calling it a day.
You could even write an HTTP and other application protocol proxy that would automatically rewrite all ipv6 addresses in HTML with ipv6 TLD addresses.
As https deployment continues to increase suggesting solutions applicable only to http sites is not operationally viable to say nothing of added systems and operational costs of deploying proxy servers to facilitate more hackery.
ISPs as a complementary measure could also offer 6over4 gateways as well, and then over time transition to allowing raw ipv6 over their networks, a transition which can be gradual.
Or just deploy IPv6. The complexity and cost at scale of these hacks are worse than dual stack deployment.
Your "solution" is a bunch of horrible hacks that don't even work with DNSSEC. Essentially you have "NAT" functioning at the DHCP+router+DNS level, all conspiring to mangle packets in concert.
IPv6 traffic is growing 300% every year and IPv4 traffic is only growing 50% every year. Give it a few more years. Once the tipping point is reached, IPv6 will become center stage.
Opps, meant 3x faster than IPv4, which is about 150%, not 300%.
This is not technically the explanation for the 2x ratio difference, at least on the Cisco platform under the microscope here. It is slightly more nuanced than that.
The TCAM entries are divided up into two bucket sizes: 72 bit buckets and 144 bit buckets.
An IPv4 address is 32 bits
An IPv6 address is 128 bits
An IPv4 FIB entry is 32-bits plus any additional bits it stores like interface and next-hop info
An IPv6 FIB entry is 128-bits plus any additional bits it stores like interface and next-hop info
128 bits do not fit into a 72-bit bucket so it gets stored in the larger 144-bit bucket.
There are multicast entries, MPLS entries, etc that all fit into one or the other of the two TCAM buckets.
The bucket sizes are 2x difference, not the amount of stored info from the address family sizes.
ZERO ZERO ONE ZERO ONE ZERO ONE ONE! Just brushing up for my next big invention: Ethernet over Voice (EoV)
Are there incentives of any kind for operators to think twice before making piecemeal routing advertisements? Is there any cost for multi-homing every rinky-dink company who thinks they are important enough to warrant such misuse?
Now that IPv4 resources are gone do operators pay out any penalty when they go off and start announcing random piecemeal /24's right and left?
I don't care if the penalty is simply a listing on a global wall of shame.
While IPv6 stands to reduce absolute need for disaggregation it will only be effective in doing so if there is some mechanism by which unnecessary advertisements carry a cost.
Can someone explain me how a protocol with bigger addresses and bigger routes fixes
a hardware resource problem.
OK, but apart from the sanitation, medicine, education, wine, public order, irrigation, roads, the fresh water system and public health, what has IPV4 ever done for us?
John
I've been a Cisco networking guy for 10+ years - the 6500 series is a Distribution/Core technology for the LAN - it's definitely been milked over the years but the 4500 series is basically designed to phase it out
some of the 7600 routers (the older bricks) - I can also understand - but seriously - if you are a core internet provider, why the hell are you using a 6500 router for the BGP routing table of the internet? Put that thing in a dorm room and buy yourself an ASR 9000
RB
----------
ah honey, we're all resplendent - Bill Mallonee
My ISP does IPv6, as does all my equipment. I had to disable it so that the rest of my family doesn't wonder why random sites don't work on their PC but work fine on their phone and while I can't remember the ones off to the top of my head, there are some big ones that regularly fuck up.
Wow, your setup sucks. My ISP offers native IPv6 and all our laptops, tablets, etc. come up with both protocols live. I have literally never, not once, zero times, ever had a problem that traced back to having IPv6 enabled. Maybe we just buy better equipment or have a better ISP or something, because it Just Works for everyone in our household.
Dewey, what part of this looks like authorities should be involved?
ABSOLUTELY FUCKING WRONG IPv6 addresses are 128bits with a 128bit mask. Every bit counts.
You have fallen to a classic blunder. Just because that bullshit SLAAC requires a 64bit prefix does NOT mean the whole damned world is 64+64. This idiot-assumption makes your entire product line completely useless; you have now bankrupt your company.
IPv6 currently has fewer prefixes, but that won't always be the case, and it uses the same TCAM space as everything else. Giving IPv4 a little more space means taking it from something else -- by default that's IPv6 space.
I believe that technically it's that the routing table is configured to use an insufficient amount the available CAM. According to Cisco, their devices all have enough memory, it's just that the default configuration only allocated 512k for the routing table.
.: Semper Absurda
Sorry, to clarify, it's 512 thousand routes worth of space, not 512 kilobytes.
.: Semper Absurda
Brought peace?
That said, how is any network of any size supposed to protect itself again ISP outages other than multihoming?
The logical place to deal with this issue would be higher up in the stack, like with SCTP's multihoming support. Rather than advertising multiple routes to the same IP address, you let the other endpoint know that you can be reached at multiple IP addresses. If one ISP has an outage, you transparently switch the traffic over to another address.
Unfortunately, this requires updating applications to use different protocols; there is no backward-compatible way to retrofit this form of multihoming into TCP or UDP.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
While in practice most admins configure /64s as subnets, there's nothing preventing netblocks that are smaller than /64. I have /127 point-to-point subnets on my network, and /96s going to server racks. You need a /64 in order to do RA, however, but you can use DHCPv6 instead on smaller subnets.
Your solution is to a problem that doesn't exist. v6 already supports a gradual rollout and transition period: all you have to do is roll it out without disabling your existing v4.
If you use SLAAC to automatically configure an address, it does it by putting the MAC (rather, EUI-64) address in the lower 64 bits. If your address comes from something other than SLAAC then it doesn't need to have the MAC address there.
Of course it won't. The internet is growing and v6 is there to handle that growth, so of course it's going to end up with more prefixes. However, the number of prefixes scales much better with network size in v6, due to the much lower HD-ratio (which is a big part of why the address space is so huge in the first place). A v6 prefix tends to take 2x the TCAM space a v4 prefix does, but v6 can handle the same number of nodes with way fewer than half the prefixes that end up being needed in v4.
You're right. It was time 10 years ago. Now it's way PAST time.
Ah don't worry, Comcast, AOL, Verizon, TimeWarner and NSA will come to the rescue. They will block EurAsia from the USA Shores and then there will be enough addresses available. There will be a new definition of Global Access.
If you want Europe, The defunct Net Neutrality rule will allow you to purchase "World" global access.
Leslie Satenstein Montreal Quebec Canada
I live and work in the UK but support offices in the US, Europe and SE Asia. Yesterday some of our network monitoring services were insisting our whole office in South Carolina was offline, despite the fact that I was at that moment screwing around with their servers remotely trying to figure out why some of our services wouldn't connect to some of our other services, pretty much bringing business completely to a halt. TWC swore up and down the fault was not with them, till eventually they acknowledged that yes, half of our businesses websites didn't work and and, yes, any traffic routed to/from BT (Britain's largest telecomm) was not reaching SC. That was yesterday, 7:30AM EST. Just now, 4:30PM EST they still have not "fixed the problem" as "not enough users have been affected." We've given up on them being useful any time soon and have routed the SC office's business-critical services through our office in Germany just to get things moving again.
I mean, I'm just IT but isn't someone at the top going to start asking these ISPs who is going to compensate them for business lost?
Netflix is better for me on v6 than it is on v4 because my ISP (Fios) does not support v6 so I have to tunnel it out, and the tunnel avoids the congested uplink that Verizon has to Netflix.
I read the internet for the articles.
Even if everyone makes a serious attempt to switch to IPv6 right now, IPv4 will be around for a while. There is not enough hardware available to replace the hardware that is not able to deal with IPv4 only. I have been ready for years. I am irritated that I cannot access anything via IPv6. As for the falsehood that we will never run out of IPv6 address's, look again. There is an end. It is way out in the future, but with everything being connected to the net, including pets, the end is coming. I hope they are working on IPvSomething past 6. We will need it.
we just run a bridge to IPv4 so it looks like IPv4 to the rest of you.
-- Tigger warning: This post may contain tiggers! --
Not on backbone routes. Backbone routes only need 48 bits. And if you use the recommended link prefix length, you don't need longer than 64 bits anywhere. 64 bit networks ought to be enough for anybody.
Even if you decide to make your link prefixes longer than 64 bits, you don't need a CAM with thousands of entries for that. Most routers don't have thousands of ports.
Do you care about the security of your wireless mouse?
The only thing intentionally done wrong, that I am aware of, is ISPs not deploying IPv6 for a decade.
Do you care about the security of your wireless mouse?
It is a problem made five times worse by the extreme high HD-ratios needed to keep IPv4 alive. If we switch to IPv6, we can go on much longer before this becomes a problem again.
It may become a problem again after IPv4 has been abandoned as the network keeps growing. Something scaling better than BGP would be nice. I predict a more scalable solution is going to need more addresses - no problem for IPv6 but would make such a scalable solution unusable with IPv4.
Do you care about the security of your wireless mouse?
You'd need more than 10^12 internet users to push the IPv6 HD ratio up to the same ridiculous level that we have on IPv4 (for those bits that matter to backbone routing). Dagger2 is right, the HD ratio does have a measurable impact on number of advertised prefixes. The average number of adverstised prefixes per AS is five times higher on IPv4 than on IPv6.
Do you care about the security of your wireless mouse?
But those are never advertised through BGP between AS. For backbone connections between AS 48 bits is sufficient. Within your own AS, you can use a hierarchical structure, which due to its hierarchical structure can be routed more efficiently.
To summarize - for the foreseeable future I guess 200k entries matching on the first 64 bits will be plenty for backbone routers. And 10k entries matching on all 128 bits will be plenty for edge routers.
Do you care about the security of your wireless mouse?
Squatting on global unicast space would not be a good idea at this time. You still want to be able to communicate with existing IPv4 backbone. Once the IPv4 backbone is ready to be deprecated, such a system could start reusing global unicast space.
Until then, RFC 1918 addresses do work just fine for the purpose. RFC 6598 addresses might be better, I haven't tested yet. Addresses from the reserved class E address space won't work well for this purpose. I tested and found that it works with some systems, but other systems refuse to communicate with peers on class E addresses.
Depends on how large a network you deploy it to. For a single broadband connection, that size is plenty. But I don't think it would be sufficient, if you want to cover an entire ISP. If you can find me a network that want to deploy it, I'll tell you how far that pool size scales.
In the end, the number of TCP connections won't even matter.
127.0.0.0/8 has special meaning in practically every IPv4 stack. Trying to redefine that won't work well.
Do you care about the security of your wireless mouse?
That didn't stop DNS64+NAT64 deployments. DNSSEC is not widely deployed, which is why IPv6 transition mechanisms that are incompatible with DNSSEC would still be usable. DNSSEC also hasn't solved the amplification attacks problem yet. I'd love to see DNSSEC deployed, but I am personally not going to put much effort into DNSSEC until the day I no longer have to worry about IPv4.
Turns out it still works better than carrier grade NAT.
Do you care about the security of your wireless mouse?
What would break if you multihomed your own address space without having your own ASN? Each of the ISPs you connect to have an ASN, which can be used to announce your address space.
Do you care about the security of your wireless mouse?
IPv4 has been around a lot longer, and has had a lot more real use and legacy concerns. Even if you got that 5× fold reduction in routing table sizes by switching everyone over to IPv6, then:
1. You won't *keep* that nice clean space. The same processes that led to IPv4 fragmentation, ex space, will start to affect IPv6: Mergers; ASes eventually running out of bits in their prefix, given enough time (and remember, we're talking routable bits - that's only 16 in a /48, a lot but not impossible to exhaust either, a /56 would be even easier to exhaust) and neighbouring prefixes no longer being available to allocate.
2. Say 1 is wrong, and v6 stays clean. Ok, you've got a 5 fold linear reduction compared to IPv4. However it still doesn't fix the problem that current Internet routing leads to O(N) routing tables at each AS in terms of number of entries (O(NlogN) in terms of total size), where N is the size of the Internet and N keeps growing at a fast rate - even if measured in # of ASes rather than # of prefixes. Certainly supra-linear, potentially exponential Internet growth to date, and we've still got much of Africa, China and India still to become rich enough to start using address space like we do in the developed world. That 5x linear reduction is, ultimately, a barely noticeable blip in the face of continued supra-linear, perhaps exponential growth of the Internet.
IPv6 doesn't fix routing table growth problems, at least not in terms of providing a mode change in how routing table sizes grow with respect to the overall network, because IPv6 does not fundamentally do anything to change how routing is done, in a way that could slow the mode of routing table growth.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
With address shortage being the main reason for fragmentation, that doesn't sound so likely.
This will not exactly lead to growth in number of announcements, but it won't lead to a reduction either. Giving incentives to renumber after a merger may help a bit. At least there should be enough addresses that the company can pick which of the two blocks it want to renumber into, and that block can be extended as needed.
Bits are set aside to allow them to grow - for now at least.
Doesn't all the RIRs hand out addresses in /32 or shorter blocks?
That is true. This problem is going to get even worse if we want end user sites to have access to dual homing. Fixing this is going to require some fundamental change to how routing is done.
But if IPv6 gets deployed soon, the reduction in routing table size should buy us some time, that can be used to come up with a more scalable solution, which will allow every site to be dual homed. But of course things will have to break if ISPs will keep waiting for breakage to happen before they start deploying scalable solutions.
If the tables grow with each generation of hardware, a 5x reduction can last a while. Not forever, but long enough that a long term solution can be deployed, if ISPs want to.
Not permanently, but IPv6 can help now, and IPv4 can be expected to get worse if allocations gets split and traded. And throwing bigger hardware at the problem may help with this one issue regarding IPv4, but there are other problems with IPv4.
Do you care about the security of your wireless mouse?
Well, let's agree to disagree to on point 1. I do agree with you though, IPv6 will be less fragmented than IPv4, though I do also think there are processes besides de-aggregation in the face of address space pressures that cause fragmentation, and I think IPv6 will face those pressures too. IPv6 needs to be seriously used first, and it may also require time.
Next, IPv6 addresses are of course 4 times larger than IPv4 addresses. Even if your IPv6 routing table has 5 times fewer entries, you're not getting a 5 times saving in memory. You're only getting a 5/4 times saving or tables that are 80% of the IPv4 - nowhere near as dramatic.
I'd contend 2 is the real underlying problem. Routing tables growing with the size of the network, in terms of # of entries - even if not at all fragmented. In terms of overall size, it's O(NlogN), however given we're using a fixed-length address label, that logN factor makes itself known in quite big jumps, as illustrated in the previous paragraph. That 20% saving will be eaten extremely quickly if the Internet keeps growing at super-linear pace. Given so much of the world's population isn't yet online, there's every reason to think the Internet still has plenty left to grow. Even in the developed world, there's no reason to think the amount of address space used per person will not grow dramatically. The amount of network enabled devices each of us own just keeps growing. The "Internet of Things" is the current buzzword, looking at network-enabling many small devices. Granted, that won't directly increase pressure on routable bits where a site upgrades to v6 from an existing v4 connection, e.g. a person's home, however there are surely many use-cases that involve new distinct locations coming online (e.g. cars?).
IPv6 is just neutral on the routing scalability question. Reduced fragmentation seems a trivial saving, at least to me.
Worse, it is possible that IPv6 is actually too small to be able to solve routing scalability.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
IPv6 didn't improve enough to be two versions ahead... let's start work on IPv7+!
IPv7 was officially deprecated in 2012. In practice IPv7 was obsolete before IPv6 was finalized.
Do you care about the security of your wireless mouse?
In IPv4 all 32 bits are used for routing, though on the backbone you tend to only accept /24s. In IPv6 the first 64 bits are used for routing, though on the backbone you tend to only accept /48s.
Either way, you only need twice as many bits in the CAM to handle an IPv6 route compared to IPv4. So what you call a 20% saving is more like a 60% saving. The picture is a bit more complicated, because two CAM entries at half the size is not the same as one of the full size. So you may have to decide at design time, how you are going to use that CAM.
I'd love to take part in solving that problem. Any realistic solution is going to start with a migration to IPv6. And I don't see how we could expect the solution to be deployed any faster, so if we start now, we could probably have it in production by 2040.
That algorithm has a major drawback. The address of a node depends on which links are up and which are not. You'd have to renumber your networks and update DNS, every time a link changing somewhere cause your address to change. If we assume that issue can be fixed, it doesn't really imply that addresses would have to be larger.
The algorithm in the paper assigns two identifications to each node. The first one could very well be the IPv6 address assigned to the node. The second address is computed based on the first address and structure of the network. However their routing looks awfully similar to source routing. So really the solution might just be to make source routing work.
I can think of a couple of other reasons to consider IPv6 addresses to be too short. That paper isn't one.
Teredo and 6to4 are two "automatic" tunnel protocols. Both embed IPv4 addresses inside IPv6 addresses. Due to the use of NAT, Teredo needs to embed two IPv4 addresses and a port number inside the IPv6 address. That doesn't leave room for a site-level-aggregator or host part. If you wanted one unified protocol which could replace both Teredo and 6to4, you'd need at least 192 bits in the IPv6 address.
After IPv6 showed up, people realized that it is sometimes convenient to embed cryptographic information inside the IP address. That was unthinkable with IPv4. With IPv6 it is doable, but you have to chose cryptographic primitives that are not exactly state of the art, due to 128 bits being a bit short for cryptographic values, and not all of them even being available for that purpose.
Do you care about the security of your wireless mouse?
Ah, yes, of course, for the CAMs (or any other relevant longest-match index) you need to only store 64 bits at worst. Still, it's not the 5 fold saving.
The Cowen algorithm: Her original paper encodes landmark output ports in the label. That's not practical because of updating. However, with some added restrictions and at the cost of a slight amount of generality (e.g. not being able to work for every posssible graph, like pure star/hub-spoke graphs), you can eliminate that and have the addresses just be (landmark,node). You can do this by having nodes not build local clusters that are overly large, and so you can allow landmarks to also maintain local cluster routing tables - eliminating the output-port hack.
The (landmark,node) association need not change too often. Outages of links in the region between landmark and destination can be dealt with as they are today with routing - the scheme has full shortest-path routing in a region around each node. No need for the label to change. Outages that affect the path between the source and the landmark also similarly are dealt with like normal routing today. The one issue would be if there is a complete loss of a local cluster shortest-path route from the landmark to the destination. Then packets would disappear.
The end-node can at least be informed of this quite quickly, through the local cluster routing protocol (which can be a slightly modified BGP). Which is better than BGP today. Dealing with such issues of landmark redundancy, i.e., having associations with multiple landmarks, are perhaps better solved at a layer above the network layer. The theory shows that it is impossible to have both sub-linear routing tables AND full, global, shortest-path routing for /everyone/. If super-linear routing state is a problem you want to have solved, you have to give up something else.
Practice suggests that those who require redundancy at scale already seek to do so above the network layer. I.e. it is already good practice to locate redundant services on different prefixes precisely to guard against routing fsck-ups and failures. That suggests multi-homing in the "global prefix for one prefix" sense is not something that you should make too many other compromises for in any new routing architecture. Even with IPv4 which does do multi-homing for all to all, BGP multi-homing is not reliable enough to rely on. So it's probably better solved at the transport layer or higher, mediated at end nodes, and not complicate or compromise routing for it, as networks will still go and implement higher-layer redundancy anyway.
Indeed, by providing 2-way signalling in the routing layer, we can make the higher-layer redundancy solutions much better. Today if you advertise a prefix, you have no idea who has and has not received it, beyond your immediate neighbours. Even for your immediate neighbours, you still don't know if they have accepted the route. You can't really improve this in a routing system where all prefixes have global visibility, the communication and state costs would likely be unacceptable. However, in a Cowen Landmark routing scheme, we could at least provide an advertising node knowledge of which landmark nodes have working local cluster connectivity back to it. That's made possible because the scope is restricted, no longer global.
Note that the routing isn't source routing. Just because the address contains (landmark,node) doesn't mean the packet goes via the landmark. As a packet gets near to a landmark it may hit a node that already has the destination in its local cluster routing region, and so the packet goes shortest-path from there to the destination - potentially skipping the landmark. It's more two-stage routing, but each stage is shortest-path, per-hop routing. The 1st stage is routing the packet towards the landmark, the 2nd is when it hits a node with the destination in its local cluster (which, in the worst case, is the landmark).
On address sizes, that's a very interesting point about Teredo and 6to4. Ye
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
Guess they only implement the even numbered IP sets... IPv8 anyone?