Freeing Up of Hundreds of Millions of IPv4 Addresses Mooted (itnews.com.au) 250
Work is afoot to free up several internet protocol version 4 (IPv4) address ranges which have been unroutable as reserved, invalid or used for loopback networks since the 1980s. Reader Bismillah shares a report: Seth Schoen, who co-founded the free transport layer security digital certificate provider Let's Encrypt is working on an IPv4 clean-up project that would take address currently not routed on the public Internet, and make them generally usable. Presenting on the IPv4 Unicast Extensions Project at the Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT), Schoen said decisions taken during the 1980s to keep several IPv4 address ranges as "special", has led to a substantial amount of numbering resources going to waste. This "even though the reasons behind the those decisions has not been borne out," Schoen said. Taking the 240/4, 0/8, 127/8, 225/8-232/8 ranges, and making them available as ordinary unicast numbering resources for networks would add some 419 million IPv4 addresses. Due to the rapid growth of the Internet, the number of 32-bit IPv4 addresses has become scarce, with some regional registries being unable to allocate additional blocks to networks. The scarcity has caused IPv4 address hoarding, high prices for sub-allocations and even fraud to get more space.
Out of curiosity. (Score:3, Insightful)
Check the DOD !! (Score:3, Interesting)
Re: (Score:2)
Interesting you think career DoD people support a man over a nation state to which they've dedicated their careers.
Re: (Score:2, Insightful)
> Trump supporters are the ones advocating for freedom of expression these days
Only because they want to be able to advocate setting fire to crowded theatres and hanging the vice-president without the FBI looking at them funny.
Re: (Score:2)
Fucking hell, I swear you fucking Trumpers feel more martyred than Jesus Christ himself.
But Trump is both greater and more humble than Jesus Christ himself ;-)
Re:Out of curiosity. (Score:5, Informative)
I doubt it.
240.x.x.x.x is a "reserved for future use" that seems to have never come to fruition.
224.x.x.x.x is multicast, and while we don't see a lot of multicast, it would definitely break a lot of IPTV implementations that assign an ip address to every channel.
0.x.x.x.x and 127.x.x.x are basically unroutable by design and will break lots of software that assumes these IP addresses are loopback.
Honestly we should be forcing ISP's to use IPv6 by now (I've had ipv6 accessible servers since 2008, so it's been 14 damn years the internet has had to move away from IPv4.)
One of the big problems is legacy software that doesn't speak IPv6. That is the problem. I can go into office buildings built before 2008 and find Cisco Catalyst 4000 switches which were retired in 2010.
See the problem? A lot of businesses big and small are using old hardware that they don't maintain properly or correctly, and thus we keep needing IPv4 because these damn places don't assign routable IPv6 addresses. Yet at the same time, it seems like these large businesses don't assign routable ipv4 addresses either, they're basically on carrier-grade NAT.
Here's how we can fix, pretty much everything:
1. Mobile devices, remove all IPv4 support. Off-by-default, only ipv4 software(0.x.x.x), local loopback(127.x.x.x) and multicast(224.x.x.x) are enabled, everything else doesn't route. If you need ipv4 you need to enable it manually. Have any ip4 requests go through a 6-to-4 server the ISP must operate.
2. SmartTV's, Tablets, Game consoles. IPv4 only operates in P2P mode (eg lan-party mode), internet requires a 6-to-4 bridge at the carrier
3. Computers, Laptops will only accept local subnet (10.x.x.x or 192.168.x.x) NAT addresses. Internet requires a 6-to-4 bridge at the carrier.
Basically use the 6-to-4 transition tech that has also existed for 11 years. https://datatracker.ietf.org/doc/html/rfc6343 (or 21 years https://datatracker.ietf.org/doc/html/rfc3056 )
If the internet "breaks" because of a lack of ipv4 space, it's because they are trying to landlord ipv4 addresses, which shouldn't even be a thing. This is what HP has. https://www.pingdom.com/blog/where-did-all-the-ip-numbers-go-the-us-department-of-defense-has-them/
US Military (Department of Defense etc.) 12 201 million
Level 3 Communications, Inc. 2 33 million
Hewlett-Packard 2 33 million
AT&T Bell Laboratories (Alcatel-Lucent) 1 16 million
AT&T Global Network Services 1 16 million
Bell-Northern Research (Nortel Networks) 1 16 million
Also note that AT&T's baby bells have merged and so has Level 3 with CenturyLink.
There's also Ford and Mercedes that seemingly have large allocations, and unless they're assigning them to cars, I don't see how they could possibly be using all of them.
Re:Out of curiosity. (Score:5, Informative)
Re: (Score:2)
Define "managing". The big problem with IP addresses is they were designed to be logically routed in blocks, not split up into small segments and spread across the globe. The result of "freeing up" IP addresses is to create ever increasing complexity for BGP routing tables, making them larger and larger. That's not sustainable.
The reason IPv6 jumped to 128bits is due to this as well. It wasn't because we thought 64bits wasn't enough for everyone, it's to facilitate sensible routing.
Re:Out of curiosity. (Score:5, Interesting)
#1 is already sort of how it works with basically every carrier I have had domestically and internationally over the past decade. The major difference is that these are often dual-stacked instead of utilizing 6-to-4 gateways (i.e. you get both a private carrier-nat'd ipv4 AND an ipv6). That's an implementation detail, as cell phones aren't "using up" ipv4 addresses, and I personally prefer to the dual-stacking since legacy apps still happily see a nat'd ipv4.
US Military (Department of Defense etc.) 12 201 million
A pittance for, you know, inventing the Internet along with Al Gore.
IPv6 is a chicken and egg problem which we are trying to solve by translating chickens into eggs without any actual incentives. In fact, all we have done is just make ipv4 addresses more financially valuable. Instead of trying to harvest a few million ipv4 addresses here and there to get through the next month, I think the SIMPLEST solution is to REQUIRE anyone applying for a new ipv4 allocation to dual-stack it with an ipv6 address reaching the same machine with the same services (i.e. you want an ipv4 and run http on it... the ipv6 you provided on your request form better also route to that same machine and be running that same http server). No matching routable ipv6 within a month and that brand new ipv4 allocation gets yanked and put back into the pool for someone else willing to play ipv6 ball. Then give everyone with an existing ipv4 block a few years (10 is perfectly reasonable given hardware turnover) to dual-stack ipv6 on top of their existing ipv4 networks or they get their arpanet-era ipv4 allocations revoked. In other words, every "new" ipv4 customer must have a routable ipv6 address in order to get ipv4 service. Every existing ipv4 customer must have an ipv6 address within a decade to continue ipv4 service.
Once everyone is running ipv6 (for fear of losing their precious ipv4 allocations) then there's simply no pain left. People can turn off ipv4 whenever they want. The current state of affairs only incentivizes hoarding.
Multicast? Kill it. (Score:2)
Really, nobody does multicast in real life. There are some OTT IPTV implementations out there, but they don't route over the public internet because nobody in their right mind allows multicast traffic onto their network.
Free it up. Why not?
Re: (Score:2)
Really, nobody does multicast in real life.
Easy to say, difficult to prove (unless you count dropping support for it, and then seeing who complains afterwards :) )
Free it up. Why not?
One good reason would be that you've got 30+ years of software and documentation out there relying on the current behavior. If you now go back and change the documented behavior to something else, at the very least you've made thousands of existing documents/books/guides/etc buggy and misleading. But worse than that, you've invalidated the programming of millions of existing devices that
Re: (Score:2)
Actually, people do use multicast. You just don't know it.
Every apple product on the planet uses it.
How do you thing all of those "it just works" things find one another?
I won't go into the number of enterprise vendors that use it for a number of things.
No children, just because YOU don't use some things, doesn't mean they aren't in widespread use with catastrophic consequences if they suddenly become routable.
Re: (Score:2)
To follow up, lookup mDNS [wikipedia.org]. Lots of "smart home" devices use it to find each other, not just Apple.
Re: (Score:2)
Why would that traffic get past the router? Why wouldn't that be internal traffic, and tunneled if it needs to go over the Internet?
Re: (Score:2)
Internet requires a 6-to-4 bridge at the carrier.
I think you mean the router that the customer has? If the need arose, some manufacturers would start making routers that do this, so that the ISP would still be IPv4-only.
Also, while in some places people can choose between multiple ISPs, there are places with only one or two options, in those places the customer would choose a different TV, one that works.
Re:Out of curiosity. (Score:5, Interesting)
Changing the Internet is basically impossible. I know that routers I took out of commission 10 years ago are in use in Africa now an likely will be for 5 more years. That means that a single life cycle of an ISP router can easily hit 20+ years. So long as software can't be updated on those devices, whatever is in those routers will stay there and replacing them isn't an option. Any such change would need to be planned 20 years ahead and would require follow through... this is why BGP is designed as it is. It allows extensions but can never actually be changed.
Then there's clients. If you visit a modern day paper mill for example. They will have SCADA based industrial control systems and routers and such. A paper mill expects the average lifespan of a system to be 80-100 years. I know, nothing lasts that long... yet I've been in many environments with 40-100 year old systems in place. Of course we know for a fact that the electronics have no chance of surviving that long, but the point I'm making here is that any routers or control systems or anything of the sort in those factories will not be replaced while I'm alive at least.
That spans everything from traffic lights to digital highway signs and such.
There are likely close to a billion or more devices on the Internet... anything from surveillance cameras to alarm sensors and more which are made by companies that are out of business or were absorbed and things like redundant products were reduced... like Tandberg telephones for example which can't be updated but will be in use a minimum of 10 more years.
Now that I've gone there, understand that as far as I can estimate, at least 80% of all Internet connected devices make forwarding decisions based on routing tables rather than dumb default routes. So anything based on Linux, Windows, BSD (pick one, any one), QNX, VxWorks and more are running full IP stacks that are fully aware of the current address usage. At least the 127.0.0.0/8 range is expressly fixed in those operating systems.
The 0.0.0.0/0 network is actively used as additional private address range in many organizations. And so far as I know, I've never heard of any problems.
224.0.0.0/4... there's no hope here... every operating system ever to understand multicast expressly ignores the unicast routing tables and either uses a multicast routing table or an alternative to process these. If this were fixable in anyway, at least in regards to IPTV providers, it wouldn't be a huge problem since almost all IPTV providers generally use 232.0.0.0/8 or 239.0.0.0/8 as they are special ranges in multicast uniquely suited for those purposes. Then there's 224.0.0.0/24 (and some odd extensions) which are reserved for link local multicast.
Everyone seems to be gung ho on what to do with users in IPv4. The answer to that is simple, NAT, CG-NAT etc... easy... done. If there are users running legacy apps which are incapable of traversing NAT, they can run a VPN and it's solved. This is not difficult or even technically challenging. A company like NordVPN could make a fortune offering that as a service.
The pubic Internet needs to work a lot harder to move towards HTTP for everything. It's the only "secure" commonly used protocol which supports session multiplexing.
With HTTP, a cloud the size of AWS could easily have a single public IP address which is anycast. There is precisely no reasons on earth that a cloud service would need more than a single public facing anycast IPv4 address. As for all the backhaul connectivity, that's what IPv6 does and even then, a service mesh would work fine as well. Same for Facebook, Apple, Microsoft, Google...
My "authoritarian asshole know-it-all" perspectives on this are based on practicalities. There are things we can actually fix on the Internet. Then there are things we can't. Fixing IPv4 routing is absolutely impossible unless we make that 20 year plan... which worked
Re: (Score:3)
Home users NEED a public address for many things, mandatory taking them away would just result in an inferior service.
The internet is designed to be a peer to peer network, not a client-server service. Take away that peer to peer nature and you hand control to a few small parties and stifle innovation. Users would be totally unable to communicate with other without relying on a third party service to relay that communication.
And even with a single public address shared between thousands of users, you still
Re: (Score:2)
Re: (Score:2)
The problem with IPv6 is that it's just confusing for many people. They just want to set up their LAN, and IPv4 makes it easy. IPv4 addresses are easy to remember and always written out in full. They understand now a NAT firewall works, how to open the ports they need. They understand how to segment the LAN with IPv4.
If IPv6 had been simpler, it would have seen wider adoption.
Re: (Score:3)
This isn't true in large corporate data centers. But the network administrators there certainly ought to be able to handle IPv6.
Re: (Score:2)
Those are the people I'm talking about. You can bet that every machine on their network has a 192.168.0.x address.
The router might support IPv6 and their machines might get assigned an IPv6 address, but they probably aren't even aware of it. When they configured their internal network with things like open ports and maybe a fixed IP address for the printer, they did it with IPv4.
Re: (Score:2)
Re: (Score:2)
If you are on a
Re: (Score:2)
I don't see why 240 and 225/8-232/8 can't be made available immediately. The others, as you have discussed, "have issues".
I think the problem with "freeing the big corporate reservations" is they may have already sprawled out inside there, establishing standards for servers, printers, regions, and any number of other classifications for grouping, and being told to "tighten their belt" would in most cases require major changes in their internal assignments and changes to their standards. Look at how any ty
Re: (Score:2)
I'm sort of curious as to what HP did when they gave up most or all of 15.0.0.0/8.
Re: (Score:2)
> 2. SmartTV's, Tablets, Game consoles. IPv4 only operates in P2P mode (eg lan-party mode), internet requires a 6-to-4 bridge at the carrier
If moving to IPv6 ends up kicking TVs offline that's a win.
Re: (Score:2)
There's a lot more to RFC 1918 space than 192.168/16. You're forgetting 10/8 and 172.16/12 completely here.
Honestly, though, if the whole public Internet refuses to route any IPv4 at all, then all IPv4 could be used at every installation behind that 6-to-4 bridge. There's no shortage if each private network can have 4 billion addresses. Anyone who needs to route directly without NAT in your scenario could just do the right thing and use IPv6.
Re: (Score:2)
The problem with this line of thinking is always the same: these organizations never used their address ranges contiguously. An organization with an old Class A in pre-CIDR days may have been assigning Class B's to individual facilities, which may have been using Class C's for different groups or departments. Each of those may have only used a handful of addresses -- but the address use would be so terribly fragmented at this point that 30+ years later trying to renumber your entire organizations network
Re: (Score:2)
Networking equipment that was in use at the time is going to be very hard to service and maintain by now. At some point the networks have to be upgraded/updated and, at that time, it makes sense to switch to NAT internally and IPv6 facing the internet.
Re: (Score:2)
Today, sure — but these organizations likely put stateful firewalls in long ago.
It’s been a number of years now, but I once worked for a large corporation that had its own /8 from back when they just handed them out like candy (in fact two,
127 is dangerous, the rest seem fine (Score:5, Insightful)
Re: 127 is dangerous, the rest seem fine (Score:5, Insightful)
There are a surprisingly large number of applications that depend in the reserved ranges. For instance:
Multicast is used extensively by real time process control. Think chemical plants, mining and manufacturing.
Loopback 8s used extensively in system test.
Private ranges are used for NAT, and carrier grade NAT.
255 addresses are broadcast.
0 is generally accepted as reserved or the network itself.
Most of rest are used for their intended purpose.
I think it would be easier to switch to v6 than to mess with v4 ip reserved ranges. In particular, a great deal of equipment and software needs to be replaced either way.
Re: (Score:3)
I think it would be easier to switch to v6 than to mess with v4 ip reserved ranges.
Indeed. That would also have the advantage of being a permanent solution rather than yet another hack.
127 risks breaking backbone and edge routers. (Score:5, Informative)
There are a surprisingly large number of applications that depend in the reserved ranges. For instance: ...
Loopback 8s used extensively in system test.
127.*.*.* is also used for inter-CPU control-plane communication in a number of devices that have multiple (sometimes hysterically many) CPUs. (It's conceptually "loopback" because it's the box talking to itself. But mainly used because it's a block of addresses that is NOT going to be needed for talking to the rest of the world, so it's not going to break anything if the box firewalls it off from getting to the control plane.)
One of the places where I know for sure this is done is a major brand of edge routers. I suspect the same is true for other brands, and for core routers.
Making 127.*.*.* globally routable, so those boxes would have to forward packets with such addresses (even if 127.0.0.* was still reserved) would thus require software changes and deployment throughout the whole Internet infrastructure. It would also risk bugs allowing packet leakage between the traffic and the control plane, potentially leading to remote exploits of the Internet's infrastructure.
Re: (Score:2)
It's not just the applications that would break, and it's not just router software you would need to update. Every medium-to-high end router sold over the last 20 years does the vast majority of its forwarding in specialized ASIC hardware, and a lot of those reserved ranges are built into that hardware. 0/8, 127/8, the fact that 225-239 are multicast -- for some huge percentage of the Internet routers you can't change those things.
Professional tunnel vision (Score:5, Interesting)
The problem is much larger than the various creative uses of 127/8. There are so many assumptions, everywhere, from blocklists to down into the code in unexpected places.
So it's going to take at least twenty years to make this global change.
As an illustration, consider "directed broadcast". This turned out to be a bad idea. So we disallow it. But we still reserve two broadcast addresses per subnet for it. Because without directed broadcast you could just pick a random-but-reserved broadcast address and reclaim two usable addresses per subnet. Which is especially nice in interconnection subnets, where a /1 becomes meaningful in the usual fashion.
Now think of how much work it would be to provide a switch to not merely turn off directed broadcast in an IPv4 stack, for everything that has an IPv4 stack. That's the order of work for this proposal as well. Because you have to check each stack, code and confguration both, it doesn't incorporate those assumptions somewhere.
Plus, it's again just doing whatever seems a good idea at the time, without really thinking about it. If you enumerate all the "special" addresses ("who am I?", "hello anyone?", "myself", "whoever's directly connected", autoconfigure, private addresses, multicast, and so on) you could pack them together in an /8 or two and free up the rest. (That includes the rfc1918 addresses. Instead a "cgnat" block got allocated.)
Now, that we weren't worrying about this back in 1981 is entirely understandable, but not wise. (It was quite wise to leave a lot on "reserved"). That someone only manages to worry about this in 2022 is a tad deficient, and a blemish on the ability of the community to govern its long-term interests.
I think this should've been discussed somewhere around 2002 at the latest, and even then we'd've had a hell of a time updating all the softare today. Now? We'll be lucky if we can do the full switch in 2040 without breaking half the infrastructure in new and interesting ways.
I think this should've been discussed and implemented along with IPv6 (and IPv6 done a lot differently; one the one hand it expects to replace IPv4 entirely, on the other hand it pretends to extend it) just in case the tech turned out to be a dud (which it did in practice) because that was an excuse to go around and "fix" all connected network stacks. Now we're going to be having to do it twice. And what's the point of that?
Re: (Score:2)
Which is especially nice in interconnection subnets, where a /1 becomes meaningful in the usual fashion.
If you by this meant using /31's for link networks, that's been a thing for 20+ years.
https://tools.ietf.org/html/rf... [ietf.org]
Re: (Score:2)
The problem is those who need it get stuck also needing V4 because of the potential viewers stuck in the stone age without V6.
I would love to just get a prefix and have a whole internet's worth of addresses I can assign and forget about V4 nd the pathetic handful of addresses that can be like pulling teeth to get. But then come the complaints from the many still stuck behind V4.
It's been nearly 30 years since V6 was defined. Perhaps anyone who hasn't managed to get off their duff and implemented by now need
Re: (Score:2)
That's just you being self-centric. IPv6 is a failed technology because nobody except a few enthousiasts wanted it despite industry-wide concensus we were going to need it badly.
Most people don't know what it is. They don't really know or want to know what IPv4 is either, they just want to type a name into a web browser and get the page. They only "want" IP at all in the sense that they want something that needs to use it. In that same sense, they "want" IPv6 because they want to continue using the web, instant twitface, and such.
Customers of a number of large ISPs are using it now and have no idea.
If we required that porn and funny cat videos must be served via IPv6 only, people e
Just delaying the inevitable... (Score:5, Interesting)
Re: (Score:3)
2001:db8:85a3:8d3::: is way uglier than 85.241.30.1
That's pretty much all there is to it
My memory sucks (Score:3)
It's within my realm to memorize an IPv4 address. However, an IPv6, haven't really tried, but it's gonna hurt. ;-)
Not that memorizing IP addresses is necessary at all now with computers/cameras in everyone's pockets.
Re: (Score:2, Informative)
It's within my realm to memorize an IPv4 address. However, an IPv6, haven't really tried, but it's gonna hurt. ;-)
Not that memorizing IP addresses is necessary at all now with computers/cameras in everyone's pockets.
Just use DNS.
Re:My memory sucks (Score:5, Insightful)
It's within my realm to memorize an IPv4 address. However, an IPv6, haven't really tried, but it's gonna hurt. ;-)
Not that memorizing IP addresses is necessary at all now with computers/cameras in everyone's pockets.
Just use DNS.
Yeah, that's the usual reflexive bad answer. When do we (IT people) generally need to directly type IPs? When we're troubleshooting something. Because something is broken. For instance... DNS.
The "just use DNS" answer doesn't address the point of "hard to memorize IPs" as an argument: utility. Expressing IPv6 addresses as hex may have been necessary but it reduced human functionality. I don't pretend to have a better solution, but I'm confident the biggest contributor to lag in IPv6 adoption isn't technical. It's "I don't want to do that bullshit". IPv4 is kind of elegant while IPv6 is... like watching a screen of green matrix code. Sure, there's meaning in there somewhere. But most of us don't want to work for fundamentals.
Put one more way... imagine a version of Dungeons and Dragons where all the +x and -x bonuses and penalties were replaced with division operations. Sure. Nerds can do division in our heads. But it's a much more taxing operation. IPv6 is like rolling 17d3 using d6s instead of 17d6.
Re: (Score:3)
It's especially a problem when DNS points to a set of load balanced proxies, or is regionally based, or someone decides to use and seriously ruin split view DNS.
Re: (Score:3)
The "just use DNS" answer doesn't address the point of "hard to memorize IPs" as an argument: utility.
Having an address-space large enough that you don't have to worry about running out of addresses (or paying exorbitant fees to acquire one) seems like another form of utility to consider.
As for IPv6 addresses being hard to memorize; that's true, but not a big problem. I find that simply putting the addresses I use often into an aliases file solves that problem pretty well. There's no need to memorize "ping 2001:db8:85a3:8d3:::" when I can just type "ping $MY_HOME_SERVER".
Re: (Score:2)
Yeah, that's the usual reflexive bad answer. When do we (IT people) generally need to directly type IPs? When we're troubleshooting something. Because something is broken. For instance... DNS.
Indeed, but typing isn't the issue. It's memorizing. And it would be quite silly to memorise IP addresses. When something (for instance... DNS) goes down, the first port of call is to look up a list of assigned IP addresses, a thing that often varies on any well setup network with DHCP.
End result: You don't memorise more than maybe 1 IPv4 address, and you don't memorise more than maybe 1 IPv6 address. And if your biggest problem is typing something with a colon in it, may I recommend leaving this "computer"
Re: (Score:2)
Do you memorize IPv4 addresses, and if so would it be a terrible thing if you forgot them? By this standard, everyone should have an 8 bit address, because then everyone can remember them all! Or just add aliases for the handful of addresses you need to know.
IPv6 does add some advantages. Ie, the MAC address is in the IP address, so trying to find however it is who is sending out bogus packets is easier. And you don't run out. And you don't need NAT (which was not invented for security even if it gets
Re: (Score:2)
You usually don't need to know the IP addresses when everything is working fine, but being able to remember an IPv4 address sure does make it a lot easier when you're setting up or troubleshooting a network.
I wouldn't consider it a deal breaker issue, but it does make the transition a lot harder to sell. Especially since the people it'll bother the most are the people who would implement the transition.
Re: (Score:2)
Do you memorize IPv4 addresses, and if so would it be a terrible thing if you forgot them?
Yes. If I forgot it, I would need to go look at the list, so it is more convenient to just remember the most-used IPs.
IPv6 does add some advantages. Ie, the MAC address is in the IP addres
I would be reassigning IPs on my LAN anyway. Two reasons - it would still be easier to remember fd00::1, fd00::2 or whatever instead of remembering the MAC addresses (what if I change the network card, do I have to update firewall rules everywhere?).
And you don't need NAT (which was not invented for security even if it gets re-used for that in some odd set ups).
Thankfully NAT for IPv6 exists. Since nobody would allocate me my own range and an ASN, I would have to get IPs from my ISP. And no, I do not w
Re: (Score:2)
It's handy when DNS is screwed up, or when DNS is deliberately obscured.
Re: (Score:2)
If only we had some sort of... I don't know... like a universal computational device... that was really good at storing, retrieving, and manipulating lots of numerical data. Those poor IT people, having to type in those long, painful digits by hand, uphill in the snow...
Re: (Score:2)
If only we had some sort of... I don't know... like a universal computational device... that was really good at storing, retrieving, and manipulating lots of numerical data. Those poor IT people, having to type in those long, painful digits by hand, uphill in the snow...
Right. The network's screwed, we need to try to ping/ssh to a bunch of switches and firewalls to try to track down what's broken. So yeah, the ideal situation is to rely on network access to get to the data store where the IPs are at. It's necessary for passwords, sure. But networking fundamentals? Not great.
Re: (Score:2)
Uglier, but also harder to remember/recite. Maybe if bubble babble or similar were adopted as a more human-friendly intermediate?
Re: (Score:2)
Google DNS. 8.8.8.8, 8.8.4.4. 2001:4860:4860::8888, 2001:4860:4860::8844.
Cloudflare DNS. 1.1.1.1, 1.0.0.1. 2001:4700:4700::64, 2001:4700:4700::6400.
Comcast DNS. 75.75.75.75, 75.75.76.76. 2001:558:feed::1, 2001:558:feed::2.
Once you have DNS, just use DNS. Remembering anyone of these is not difficult. And pretty much all of the other major DNS providers are pretty similar in ease to remember, but you literally just need one to have enough to find every other one.
Re: (Score:2)
Totally agree. IPv6 addresses are simply incomprehensible to non techies. Using hex means an "average" user is just going to see it as a meaningless, incomprehensible blob of "letter salad".
It would have made more sense if they could have come up with a scheme where IPv6 addresses could be specified in a way that made them look like a longer IPv4 address.
Re: (Score:2)
You realize that's just presentation, right? It could as well be 32.2.13.184.133.163.8.211... Is that really any better? Likewise the IPv4 address could be expressed as 1,441,865,217.
The fact is, we need more addresses that IPv4 can handle. No soloution exists that doesn't involve more or bigger numbers than IPv4 has.
Side note, I would have added the trailing zeros but the /. filter is dumber than a sack of hammers so it thought it was ASCII art.
Re: (Score:3)
If there's a shortage we can always try fracking, right?
Re: (Score:2)
Because the creators of IPv6 hate NAT and so deployment in existing LANs which use NAT is more complicated than it needs to be.
Re: (Score:2)
They also hate elementary, light-weight security steps like NAT rather than compelling every user to have their own sophisticated, stateful firewall which the proponents will happily sell support for. I've seen this done in internal networks by people who deliberately mangled their own internal networks in ways only they, individually, could maintain. I've helped replace a few of those people with much simpler internal only non-routable IPv4 addresses and an exposed proxy, NAT, or both.
Re: (Score:3)
NAT isn't a security step. It provides no security and therefore can't be a security step, light-weight or otherwise. In fact it generally does exactly the opposite -- it's mostly used to try to save connections that would otherwise have failed, and it also confuses people about the security properties of their network. Neither of these things are good for security.
This isn't hating NAT, it's just using the right tool for the right job. You shouldn't have any address exhaustion issues in v6, so in v6 NAT sh
Re:Just delaying the inevitable... (Score:4, Insightful)
NAT is used, extensively, to reduce exposure of internal services to the outside world. Very, very few homes and businesses do not use it. Reducing the attack surface by blocking popular vulnerabilities is a low cost, low effort start to securing a local network. There are many fanboys of using IPv6 and maintaining sophisticated, potent firewalls. Unfortunately, the cost of providing and maintaining those is a cost many households don't care to and are unwilling to invest in, and the built-in NAT of their local router is about what they can afford. If more sophisticated sites seek more sphisticated security, they can put it behind the NAT, and use NAT to reduce the risk of users exposing RDP, VNC, SSH, CIFS, NFS, HTTP, HTTPS, FTP, LDAP, SMTP,
and other services ill-secured by corporate or home users, or refusing to expose them without specific buy-in from the NAT owner and only exposing them on non-standard ports or through a maintained proxy.
Re: (Score:2)
It's used extensively to deal with address exhaustion, not for security purposes. It's also used extensively by people who think it provides security, but that doesn't mean it provides security.
Firewalls are simple and provided by default built-in to home routers, just like NAT. They're not some extra cost that people have to deal with. They don't need to be "sophisticated and potent" either; all you need is a simple "deny inbound connections by default". NAT is far more complicated than that, and imposes a
Re: (Score:2)
Re: (Score:2)
NAT is a good tool even you ignore the claims that NAT brings "security". The refusal of IPv6 to treat NAT as first class citizen and refusal to streamline NAT in the first place is one of the major reasons IPv6 still isn't used as widespread as its supporters wish.
I won't defend CG-NAT but intranet NAT simplifies networking a lot. Without intranet NAT, the only 2 ways for a device to get an IP is either by device manufacturers or by internet providers. That means an intranet cannot keep its IPs fixed fu
Re: (Score:2)
Do you REALLY need to remember the IP of the DNS server though? If you have an address, you have RAs on the network. The RA can easily distribute the DNS IPs as well. So if you can talk at all, you can resolve names.
Sure, this doesn't help with servers you static assign. But in that case you probably have some documentation in front of you while setting up the OS. Or, for more fancy setups, something like Ansible. You could also just use SLAAC to start up, then use that to get the info to set up your static
Re: (Score:2)
Despite assertions to the contrary, NAT is an excellent security tool. It makes it much more difficult for adversaries, even if they see outbound traffic, to reach and target a particular host. My company just rolled out zScaler and I'm sure there are similar competitors out there in the IPv4 space.
All traffic is TCP-fo
We're not afraid of change (Score:4, Interesting)
It's more that it's a bidirectional chicken-and-egg problem, but backwards.
There's no motivation on the client side to use IPv6 because if you have IPv4, whether directly or through NAT, you can access the entire Internet. You're not "missing out" on anything other than incoming connections if you're on NAT, and most people don't need that capability.
There's no motivation on the server side to use IPv6 because if you have IPv4, everyone can reach you. Period. There's still a lot of IPv4 space available, it's just owned by big cloud providers like AWS where people tend to put their services up anyway.
Full IPv6 adoption will not happen until it becomes a lot more painful to not use IPv6, and sadly that's not going to happen anytime soon. Mobile providers use IPv6 by necessity due to the sheer number of clients, and many are already pure IPv6 and using 464XLAT to get to IPv4. In the end this is NAT with extra steps. We get closer every year, but each year we travel about half the distance, so we're not getting there any time soon. :(
Re: (Score:2)
It also will not occur until a great deal of old hardware and software is obsolete.
Re: (Score:2)
>Swell nice to hear the largest providers are doing well. It would be a shame if anyone wanted to compete and had to fight for scraps or if people wanted a prefix to run their own shit and their ISP charged them extra. What's there not to love about a completely unnecessary multi-billion dollar market (e.g. tax) bankrolled by customers?
Just wanted to say I agree completely. It sucks that Amazon owns so much IPv4 space and thus has so much sway over the market. That doesn't change the fact that they do, t
Re: (Score:3)
At the university the network was born as DECNET one, because there were a lot of Vaxen, but they added TCP/IP networking because there was use for it. A transition to IPv6 should have been stared years ago: trying to scrape the bottom of the barrel isn't going to solve the problem, but only
Re: (Score:3)
You'll need to provide replacements. (Score:2)
You can't just have them to make a buck, you greedy scumbags.
I pity the poor fucker who gets 0.0.0.0 (Score:4, Funny)
Re: (Score:3)
On DSL if they're lucky. That address is so old it's probably on an analog line!
Re: (Score:2)
Audi?
Just move to IPv6 already. (Score:4, Insightful)
It's been over 20 years ffs! Just move to IPv6.
Re: (Score:2)
It's been over 20 years ffs! Just move to IPv6.
I am with you on this! Enough IPv4 already.
Re: Just move to IPv6 already. (Score:2)
Agreed.
Re: (Score:2)
Re: (Score:2)
Except on Windows, unless you want to get hacked (look it up).
You made the claim, post a link. No we're not going to look up shit to validate your pointless claim.
0 and 127, no way. (Score:4, Insightful)
The 0.x and 127.x are both problematic as there is a ton of code around them. Local network and localhost are well known. The inertia behind these is huge as they are easily remembered and often used, hard coded, and special cased.
The 225-232 and 240 are less trouble since they are usually not looked up. Some people know about them, but they are marked as test and reserved so far less likely to have been coded around. Because of the early designations they are less likely to have issues on existing infrastructure.
Re: (Score:3)
Re: (Score:2)
240. is used by mDNS and Apple's Bonjour protocol as well as many self-configuring mesh devices.
Not evenly spread (Score:2)
240/4 is 16 million and 225/8-232/8 is 8 million. The others are only one [binary] million each.
Re: (Score:2)
Sorry, off by a factor of 16 -- 240/4 is 256 [binary] million, 225/8-232/8 (225/5?) is 128 and each /8 is 16.
Re: Not evenly spread (Score:2)
240/8 is also very, very important to leave as is.
I use 127/8 (Score:5, Interesting)
Most systems have 127.0.0.1 as the IP on the loopback device and never think about it being a /8 network, but it is, and it's very useful. I use this every day. The problem is when I want to access a remote system through an ssh tunnel, forwarding ports back to my local system. (For security reasons, many of the systems I'm connecting to have firewalls that only let an authenticated ssh connection through, so tunneling it is.) I could track the port numbers and assign them all in 127.0.0.1, using some complicated mapping taking into account that I might be forwarding ports back from several different systems, all using the same port numbers on the remote end. That gets really complicated when I have some application that for stupid reasons doesn't have a command-line option to override the default port number, so while I could use iptables to set up rules to intercept connections to the remote system's real IP and use the local tunneled ports instead, that gets really ugly really fast, and requires root access.
So instead, I set tunnel back to a different loopback IP address for each system I'm connecting to. For example, I can forward 10.1.2.3:80 to 127.1.2.3:80. Then all my tools work just like normal, only using 127. instead of 10. as the IP address once the tunnel is up.
This works so well that I set up a script for hundreds of developers to use for connecting to our test systems in the lab, and nobody ever asked me about the redirection part, as it's almost entirely transparent. (The script that sets up the tunneling also launches the tools, using the loopback IP address instead of the real IP address.)
Creative IP Use (Score:3)
The seemingly simpler answer is to just take away unused IP address ranges from the big old companies. But you might be surprised at some of the creative ways some addresses have been used. Here's one:
We have a product that potentially has hundreds of components all with their own IP addresses. We originally used internal IP addresses, but we had a problem. There's a gateway system that monitors those internal components, but also talks to the customer's network. So if the customer happens to be using that same internal IP address range in their datacenter, then our gateway needs to talk to the same IP address ranges through two different interfaces. Lots of fun there.
But we're a really big company that has bought lots of other companies over the years, acquiring some routable IP addresses along the way. So for our product, we took a set of routable IP addresses that belong to us, but we weren't using, and we used those for our internal device IP addresses. Now our gateway device knows it will never need to use that IP address range when talking to the customer's network, and everything works great.
The only issue is that while we don't actually advertise that IP range as routing to anywhere, our product would break if we ever lost that IP range and it was assigned to one of our customers. I suppose if we used an IP range owned by one of our competitors, nothing could go wrong... :)
Re: (Score:2)
What you're describing there isn't creative, it's literally how IP was designed to work, precisely because of the problems you encountered when you weren't doing it.
Re: (Score:2)
If you were designing such a product today, I hope that you would not have those devices listening for TCP connections. Instead the devices and the monitoring gateway would both initiate connections to a well-known host that would broker communications. However, I can'
Re: (Score:2)
I think you misunderstand the problem. I have a pretty good idea what product is being discussed. The 'monitor' has 2 NICs - one connects to the internal product network, the other connects to the customer network. The issue is not one of the internal things being reachable by the customer (that is all firewalled off). If the 'internal' network used, for instance, the 192.168/16 network, and the customer also happened to be using that range, you could potentially have the same address for 2 different de
It is a shortage of routes not addresses (Score:2)
We are running out of addresses because of stupid routing rules that have been around ever since the Cisco AGS+ first ran out of memory for BGP.
My proposal at that time was to only allocate /24 address and not have them contiguous to encourage the router companies to make routers that could deal with 16 million routes with the goal of going to 2^28 routes in 10 years.
I have dual homed internet at home but I'm wasting most of a /24 because no one will route a /28 which is all I need. IPv6 doesn't fix that p
Re: (Score:2)
It's not. We have more devices that want to be connected to the internet than there are total IPs in v4, so even if you went down to the minimum of /32 routes v4 still wouldn't be big enough.
The minimum routable prefix size in v6 is /48, and there are about 5000 /48s per person on the planet. It sounds like you want more like a /44, and there are 300 of those per person on the planet. That's more /44s than most people have devices, and each /44 has sixteen /48s, each of which can handle a sprawling network
He can take (Score:4)
The mbone addresses out if my vokd, dead hands. Multicast is vital.
And as most have had the wits to go to ipv6, and as snat/dnat work well, freeing up ipv4 addresses is stupid.
I can see major problems. (Score:2)
This will cause chaos (Score:3)
This is a horrible idea and there doesn't seem to be any good reason to proceed. Unfortunately, I'm sure this figures into some BUSINESS CASE somewhere, so it's likely inevitable
Bad article title (Score:2)
Re: (Score:2)
Re: (Score:2)