> [...] if you want to get a /24 block from RIPE NCC when you sign up as a member, then you are currently looking at a 2 month wait for a recycled IPv4 /24 block.
That's a rather optimistic view of the situation. The next member who will get a block has already been waiting for 2 months and it's unclear when they will get one. It stands to reason that members applying now wold have to wait (potentially significantly) more than 2 months.
> Should change to a montly fee. Then people would get rid of the ones not used.
There is a fee. Your EUR 1,400 annual fee.
For that money you get one IPv4 and one IPv6 (IPv4 subject to availability, obvs!).
Above that they charge per resource assignment, 50EUR per annum per resource assignment ( defined as: "IPv4 and IPv6 PI assignments; Anycast assignments; IPv4 and IPv6 IXP assignments; and Legacy IPv4 resource registrations through a sponsoring LIR. AS Numbers are excluded from this charge")
And yes, I think the 50EUR should be put on a ladder scale so hoarders get charged exponentially more. ;-)
Which is essentially what is already happening. There was a minor uproar, that seems to have died out, on the RIPE address policy working group listserv over companies and individuals signing up for multiple RIPE accounts (called LIRs) to be able to get multiple /24 allocations from the waiting list. People register multiple LIRs primarily because the cost of signing up for a RIPE account--prior to 2022, it was a 2,000EUR sign-up fee and then a prorated portion of 1,400EUR annual fee, now it is a 1,000EUR sign-up fee and 1,400EUR annual--and waiting out the two years for IPv4 addresses to be eligible for transfer is a fraction of the price a /24 can fetch on the address resale market.
Several people on the list, including someone who has made quite the sum from collecting allocations and then reselling them, were outraged that this is going on and deem it in violation of the spirit of the waiting list (that spirit being that it is supposed to give small entrants one last method of getting onto the Internet with their own /24). One of the proposed changes is to make transfers of IPv4 space received via the waiting list non-transferable retroactive to January 2021. Of course, transfers that have already happened wouldn't be reversed, since that wouldn't "be fair." Thus, all of the people who got the last "free" /22 blocks around November 2019 and who have gone on to resell those addresses (like the participant on the list who is now advocating that addresses shouldn't be allowed to be transferred) when the 24-month transfer delay expired get to keep their gains. Everyone who comes after who signed up under those rules gets the rules changed out from underneath them.
The whole system of dealing with IPv4 assignments and allocations has gotten completely out of hand. We have these large entities all acting like they are just volunteers doing a charitable thing keeping this polite ad-hoc system going, when that hasn't been true for at least a decade.
Which was one of the several points raised on the discussion at the time along with the idea that it would only embolden the address speculators trying to use the waitlist. The theory was that the speculators would go to the trouble of making shell companies or "gaming" a transfer as part of a merger-and-acquisition, while so-called legitimate users would either not bother or would just go to the secondary market from the beginning.
About 10 years ago, IBM used to use the 9.0.0.0/8 space in basically exactly the same way as one would use 10.0.0.0/8, for internal-only networking. Each workstation got its own 9.x.x.x IP, but it wasn't routable from outside.
Why would that be relevant here (or sibling comment about Apple)? Last I checked except for 9.9.9.0/24 (to quad9) IBM is indeed the assignee for 9.0.0.0/8 from back in 1992. Apple got 17.0.0.0/8 back in 1990. Back in the day a lot of big entities got whole /8 blocks (including of course a lot of the USG but private corps as well). Many of them are still around and fully active, while others are defunct (Halliburton had a /8 and that went back to ARIN then out to registries) and/or have shifted (like IIRC Amazon now has 3.0.0.0/8 but that was General Electric originally). That's not squatting, that's just making use of what they have.
>I hope they stopped doing that, but I doubt it.
Why should they stop? Ideally we'd have had at least 64-bit or better 128-bit from the beginning in a nicer form then IPv6 ended up and then every single one of us could have millions of IPs if we wished. That isn't how it ended up but that doesn't mean those who got them shouldn't use them. I make use of my minuscule bit of public IPv4 for my own stuff.
Here's a little different approach to the issue: because IBM is using IP addresses the way they were intended. Private IP ranges are not a good thing, they are a necessary evil.
NAT was developed as essentially a hack, originally more to solve tricky routing situations, but later more to allow broad use of reserved range IPs. But the original intent was always that all hosts would have a unique address, regardless of where they were or were not reachable form (or advertised to). This is a significantly better situation than the modern world of widespread use of reserved ranges and NAT, because it meant that there would not be addressing conflicts even between two private networks. Or, more practically, it meant that setting up tunneled connectivity (VPN, MPLS, whatever) between networks not advertised to the public internet always works properly, because those networks are using IP addressing as intended and thus can simply advertise their routes to each other.
Private IP ranges for "private" hosts are an adaptation to the limitations of IPv4 space, not any kind of design ideal. It's an awkward solution to a bad problem that makes numerous real-world IT situations more difficult, most commonly the case of setting up VPNs between private networks and being forced to introduce NAT because they are both using overlapping private IP space.
A very common but small example of this is the need to choose "unusual" private IP prefixes for VPN networks (like 10.106.41.0/24 or something else sort of randomly selected), because if you use something "simple" like 192.168.1.0/24 or 10.0.0.0/24 you are 100% guaranteed to run into route conflicts because of people's home and small business networks using these ranges internally. If everyone used properly allocated IPs, even on private networks, we simply wouldn't have this problem!
IPv6 offers us a bit of a reset opportunity since it was designed to have enough /64s available to allow use on private networks. Hopefully people understand this and use IPv6 the way it was intended!
You spoke of one of my most annoying issues as a VPN user. Ultimately I resolved it by myself using a non-standard private IP range at home. Any IT person that might ever use 192.168.0.0/16 space for their VPN network is an absolute masochist.
For some applications, it's valuable to have globally-unique addresses even if they're not (all) broadly accessible from the open Internet. For example, if you're building private links between networks which don't share an authority for distributing private network addresses (they're administered by different companies or organizations perhaps). I don't know how common this is anymore, but I've seen it in the past.
> For some applications, it's valuable to have globally-unique addresses even if they're not (all) broadly accessible from the open Internet.
For a real-life example of that: according to documentation which can be found at its website, the Brazilian Central Bank has been allocated a full /18 for the national inter-bank network; each financial institution connected to that network receives a /27 or a /28 (or a pair of them) from that range. If you look up that address range on bgp.he.net, you'll find out that it's not announced to the public Internet at all.
I'm curious what you mean by this. RFC1918 is just an update for earlier RFCs that go back farther in time, like RFC1597. And IBM people are credited on the relevant RFCs.
IBM is basically hoarding a bunch of addresses where there's no technical reason to. I get that they aren't required to do anything about it, but it does seem topically relevant.
You might want to allow specific machines to be addressable from the internet. Also, NATs were buggy back then and many pieces of software simply wouldn't work unless you had a real IP address. VLANs and other advanced router features didn't really exist, either.
It's irrelevant. Even if the authority existed to reclaim all the /8s handed out to private companies (it doesn't) you'd kick the can down the road a few years at best. Then we'd be right back in the same boat.
There are only ~4 billion IPv4 addresses. There are more than that many humans alive, most of whom have or will have a smartphone. So we're already short on addresses without considering network equipment, servers, IoT, or anything else.
If they own the IP space they can do with it as they please. They've had it since 1992.
It reminds me of the nouveau urbanists that move into places like SF in droves then instantly start complaining that the little old lady down the street, who has lived in the same house for 50 years, is being greedy and wasteful because she doesn't sell her family home to developers who will build 50 shoebox condos in its place.
I suspect most of the "10/8 ought to be enough for anyone" crowd has never worked on a complex enterprise network. Just because a netblock is in use doesn't mean it has to be routable to the Internet.
The problem isn't with IBM. The problem is all the cloud BS -- the 18,000th food delivery app that no one asked for -- isn't using IPv6. And that's just pure laziness on the developers' part.
Of a highly constrained resource, they're using a tiny fraction of what they've been given. That's a weird definition of "using what they have."
If I asked for a class C for my business running a local corner store, I'd be looked at like I was crazy.
IBM gets 16 million public IPs and it's cool?
Yeah, I know you can't perfectly use an IP space, but with 128 offices, IBM could give each office an allocation of around a hundred thousand IP addresses (rounding down by over 20%. But even if it were 10,000 - that's still absurd.)
It may be difficult to understand now, but back in the 90's, addresses were handed out like candy. IBM got their allocation in the late 80's.
I worked for a couple of small and mid-sized companies that had /16's and larger. And we barely used a fraction of that space.
I have a /24, personally, registered back in 1993. It's routed to my home network. I know several other folks who were on the early internet, and had the same.
Over at a University we run, we like to run like a ISP and only have a /16 to work with, its very tight even now, we have thousands of students using the Wifi, Dorm Networks and such. I do wish we had more.
We are at least at the ISP I work for. That is a major project for us this year, but any network engineer can tell you that deploying IPv6 is not straight forward at the ISP level. Getting everyone together on how to have some standard form of addressing from different entities is the toughest lift. Get Juniper, Cisco, and Arista on the phone and you will get three different ways on how to deploy it. You don't want to be the odd duck once the dust settles.
Interesting. What are the big differences if you're allowed to talk about it? I have no doubt that the IPv6 rollout is difficult, I helped move some simply cloud stuff to IPv6 and even that had a few issues. I'm much happier without the heavy layers of NAT though.
> If I asked for a class C for my business running a local corner store, I'd be looked at like I was crazy.
I asked for a /22 of IPv4 for my home, and was given it, 3 years ago. I also got a /32 of IPv6, and a 32bit ASN to do BGP with.
I paid the signup fees to become an LIR, paid the membership fees, and requested my /22, /32, and ASN allocations. There were no looks, crazy or otherwise. The policies are pretty transparent. Pay money, receive resources.
That said, the policies have since changed (about a year ago?)
> If you want to pick on a company for hogging IPv4 space, pick on Apple. They have a /8 and probably aren't using any of it.
Most (if not all) of Apple's infrastructure uses their /8 block. With Apple Park they've moved to using a 10/8 with NAT for talking to the outside. Between iCloud, iTMS/App Store, and iMessage Apple's got a non-trivial amount of global network infrastructure beyond just their corporate network.
So I guess be mad at Apple for using their IP space?
Everyone was talking about domain name squatting but turns out its been IP addresses this whole time :-D
But that does definitely seem like an excessive amount for them to own. I would guess the huge swathes the government has reserved are not exactly being used to their potential either.
We have run out of freely allocatable IPv4 and equipment isn't catching up to IPv6 - it's very relevant here.
Neither Apple, not IBM, actually need that many publicly useful set of IPs. IBM would be smart to sell them off. Apple is probably going to sit on them. (I used to work at IBM and that 9 block was very confusing to me, considering that IBM isn't even that big of a DC operator these days)
IBM owned 9/8 so this is a legitimate use of address space. All hosts should have globally unique addresses, even if you want to use NAT to hide various things. IBM does multiple acquisitions per year. Imagine merging two corporate networks that both use 10/8; it's a nightmare.
> Imagine merging two corporate networks that both use 10/8; it's a nightmare.
This is a nightmare even inside companies. Two teams set up a default VPC, and one day you go to peer them and find that the IP ranges conflict. At my last job, I ended up using Netbox to manage our private IP ranges alongside our public IP ranges. (In theory, it would be nice if cloud providers offered this feature. "8 other VPCs on this account also use 10.0.0.0/8. Are you sure you want to be the 9th?")
I do not know IBM’s current practice but in the 1990s acquisitions continued to use their internal networking for quite a long time, just interconnecting the networks as necessary and announcing routes internally.
9. addresses only started being used widely inside IBM around 1992 as the internal multi protocol network rolled out (combining RSCS over SNA and TCP/IP). As APPC connected devices gave way to TCP/IP connected devices allocations shot upward, IIRC each major campus was a /16.
Advantis/IBM Global Network ran the 9 network on the same physical and logical circuits as the public networks they managed, leading me to bypass the IBM firewall unintentionally multiple times as the filters they used broke. This may be one of the reasons RFC1918 addresses were discouraged (at least through 12/2001 when I left).
The acquisition's IPs might not conflict with IBMs, but surely they conflict with those of the other acquisitions? Is there any benefit after the first acquisition?
My point is that if every company uses real IPs then you can merge networks with no conflicts. 10/8 is fine for home use but not for enterprise networks.
In a word where any medium sized company could just get a /20 network and any enterprise could get a /8 I would agree, but with IPv4 we live in a world where the vast majority of companies don't have anything but 10/8 (and a couple of IPs for public facing stuff).
The only real options besides 10/8 are to have been big at the advent of the internet (like IBM or Apple) or misappropriate one of those IP blocks in the hope it never becomes publicly routable.
HP did the same for 15.0.0.0/8 and 16.0.0.0/8 until the HP/HPE split at which point I think they couldn't figure out who should get the address space. As 2 x /8 is pretty valuable, they sold off chunks of it and are presumably still doing so.
Ironically, having such addresses was sort of useful when companies got acquired and teams got shifted around. Starting to use an acquired company's network that was never designed with "what if we get acquired and have to play nice with others" in mind causes all sorts of routing pain.
Even the article defined it as IP space not owned.
From the parent article "I will define IP address squatting as “using IP addresses that are not RFC1918 defined and not your unicast space issued by a RIR”."
Unless this is meant to construe all legacy assignments as "squatting" which is a pants on head definition.
I dont disagree, there might-should be clawback provisions for those legacy allocations.
But how do you define 'use' they could easily 'use' them by simply announcing them via BGP and null routing the traffic to the IP's they don't want exposed?
The end answer is still IPv6, where everyone can have as much or as little IP space as they want.
Can they make a plausible spreadsheet showing use. But, clawback of IP allocations is very rare, even for allocations that were made with agreements allowing it. There's some high profile cases relating to fraud, but otherwise nope. Legacy allocations would be nice to clean up, but if it's not voluntary, it's not happening. And at this point, if it happens, it's probably going to be a sale rather than a return.
GE did the same with 3.0.0.0/8 until they sold it to Amazon. When Amazon started actually using those addresses, it created a situation known internally as the “threepocalypse”.
Am I the only one alarmed that WD maintains a public registry (via DNS) of MyCloud device UUIDs, their public IP, and their private IP? How many of those are on networks with exploitable routers?
Like, you have an external entrypoint and a target internal IP that you know will contain a trove of potentially interesting data.
I agree that's a ridiculous privacy issue. Definitely a case of poor security to provide a minor inconvenience (access your data from anywhere on the internet).
Didn't they actually recently recommend people disable direct Internet access and UPnP? I believe it was after a vulnerability was discovered in one of their legacy products.
Interesting work, but IMHO anything that extends the life of IPv4 does active harm. I'd prefer if these addresses stay out of the pool so scarcity increases and forces people to upgrade.
IPv4 is fundamentally too small, period. There are already more people and computers on Earth than possible IPv4 addresses even if it were perfectly optimally used. It leads us further down a path in which everything is behind increasingly starved NATs, making point to point connectivity more and more difficult. Now we are seeing NATs in front of carrier-grade NAT and other madness.
... and no, NAT is not a security feature. You can and almost always do have a firewall in front of IPv6. If you really want NAT there is IPv6 NAT, but it allows you to have all mappings be 1:1 eliminating the need for port starvation madness and making P2P always work. All internal IPs get their own external IP, but those can be random and rotated if you want.
Yeah I admire all of the efforts people are proposing, but they are bailing out a sinking ship with a spoon.
Let's say we claw back /8 networks somehow and let's say we can free up one of those /8 networks per year. Pretty optimistic.
The allocation rate for /8 networks from IANA after conservation measures were put in place was still 5 /8 networks per year. Even if we conserved IP addresses five times better than that, this would still merely freeze the current situation for a few until we run out once again.
There is just no amount of crumb picking that can fix the fact that 32 bits are woefully inadequate.
The total population I don't find to be a very strong argument, because all that matters is the population of people who desire to communicate with my service. If people not able to communicate with my service also don't want to communicate with my service and I don't see a need for them to communicate with my service, why do we both need the same protocols?
Something I have observed is that sites that tend to attract DDoS attacks tend not to use IPv6 (note that reddit and HN do not have AAAA records, though I don't know the actual reason for this). I've even seen the heavily attacked sites that I know are using paid Cloudflare or Sucuri services to not have AAAA records, and I wonder if that's a decision or recommendation from the service providers. So, elimination of IPv4 may mean that sites can more easily and cheaply be knocked off the Internet.
As for point one: I'm not talking about client/server access to services. I'm talking about the capacity for endpoints to talk to each other. IPv4 would be fine if we want a fully centralized computing infrastructure where everything is only a thin client, but that's a future with zero privacy or personal freedom.
I don't think there's anything special about IPv4 in terms of DDOS mitigation. What you're probably seeing is an artifact of focus and investment. IPv4 is still the lowest common denominator standard. Virtually everyone can talk to an IPv4 endpoint. As a result the DDOS protection services still mostly use IPv4 endpoints because it reduces the amount of attack surface they have to protect. If they were dual-stack they would have to deal with BGP black holing on what amounts to two BGP networks instead of just one.
DDOS is something that desperately needs a more comprehensive solution, but it's a hard problem to solve. Right now the solution is for DDOS protection services to run bastions with enough bandwidth to absorb attacks, but that's a solution that constricts innovation tremendously. I feel like a permanent solution would require cryptography to be designed into the entire network so that you could do things like rate limit packets to your host for people who didn't present a certificate. That would require a deep redesign of the entire network though, and that's not going to happen.
I'm not clear that IPv4 doesn't offer at least one measure of reduction against a DDoS, and that's just one time hits every second from 1 quadrillion unique IPv6 addresses. You simply can't have that level of problem in IPv4. However, I have never been on the inside of a DDoS attack, so I don't speak from experience on this.
In regards to mitigation, what we are talking about is an exclusive network with central controllers in the form of ICANN. Every packet has digital footprints, so what ICANN could do is permit IP address blocks to be seized and transferred when it is demonstrated the owners are consistently using the network for purposes of doing harm, even when it is through negligence. This would work its way through the service level agreements between various ISPs. As in the rest of the business world, you cannot just dump your garbage onto someone's property without eventually being forced to pay for it.
IPv6 /64 prefixes are analogous to the role IPv4 addresses typically play. Most cloud endpoints have one or more /64s and most endpoint connections from ISPs get a /64. Yes this does mean your house can have 18,446,744,073,709,551,616 devices in it with unique public addresses, but they're behind one /64.
When DDOS black holing is done the recipient will actually look up the BGP advertised prefix from which the attack is coming and black hole the whole thing. Many IPv6 prefixes are /32 and /48.
I am pretty deeply familiar with this stuff. There's nothing about IPv6 that makes current mitigation techniques much harder. The most logical explanation for IPv4-only in the DDOS protection world is just to limit the attack surface by picking the lowest common denominator address. That way you only have to defend in the IPv4 realm instead of in two addressing realms.
IPv6-only would give you the same effect but there are still too many edge devices without IPv6 addresses to use IPv6 alone for anything public facing. IPv6-only systems are sometimes used in private networks, as bastion boxes, etc.
With spoofed addresses (which are not uncommon in ddos attacks) you have exactly the same issue with IPv4. And I don't really see it making any difference if the packets contain 32bit of random information or 128bit.
One minor philosophical question. If you are using AWS PrivateLink because your VPC is not connected to the internet are you really squatting anything? You are just aren't using the public internet. This means that you own the entire address space and can decide what you want to do with it.
Of course it still may make sense to stick to ranges you own in case you need to peer your VPC with someone else, but I don't see much difference between using some random batch of IPs that you don't "own" on the public internet vs any block reserved for internal use. Either can conflict with someone that you want to merge with.
That's not really what the author was getting at. The VPC endpoints just provide a way (via TLS certificate authority logs) for the author to discover DNS addresses that they can then use to check for queries and determine what IP addresses are being used in private networks.
They found a number of AWS users that are treating publicly routable IP space as their own private IP space. If someone were to ever offer a public service in that IP space, the company/network using it as private IPs would not be able to access the public service.
The author is trying to understand how prevalent this is, and to what extent of trouble an owner of these IP spaces would have if they decided to host a public service.
I agree with you in general. If you do expect to be able to connect to the public internet and map an endpoint over a public address you are aiming a gun at your foot. However the point I was trying to make was about this quote:
> This is useful since it can remove the need for some servers to have any outbound internet access at all.
My point is that if you are not connected to the public internet at all I don't see why you should be expected to follow the rules of the public internet (who owns what). You can use whatever rules you want for your own private network.
For what it's worth, I've these endpoints in use for VPCs that still had internet access. Meaning that if you attempted to read the "real" internet address you put your VPC subnet on, they would be unreachable.
It's hard/impossible to figure out if the VPC in question has been setup this way. But I agree that it would be likely that most of these VPC with the endpoints on don't have internet access.
However if we assume (dangerously I suppose) that the VPC subnet distribution is similar to other VPCs without private link, we can imagine how many other VPCs are squatting on space that do have internet access!
For sure, I'd bet that most of the examples you found were still connected to the internet. I don't think the findings are any less valid I just thought it was an interesting observation that if you are in fact disconnected from the internet there isn't really any reason you should follow the public internet's rules.
>My point is that if you are not connected to the public internet at all I don't see why you should be expected to follow the rules of the public internet (who owns what). You can use whatever rules you want for your own private network.
Hypothetically if you were dealing with a network that had zero access to the outside world then you are right, it doesn't matter. You can use whatever IPs you want and it wouldn't make a difference.
Its a bit of a moot point though since outside of niche situations like high security air gapped networks you don't really see that scenario anymore. Yes, the network at a nuclear missile silo could do that but everyone else is connected to the internet.
This particular survey finds things that are connected to the public internet. For example, the WD NASes used are specifically those NASes whose owners have chosen to connect them to the public internet.
The squatters probably don't intend anything at all evil, but their address use conflicts with access to the general net. If you addresses that aren't yours and you expect to be able to connect to web sites in general, you might by chance use an address that is later allocated to a web site you'll want to use. If you squat on 193.168/16, that's 2¹⁶ addresses and you might block your own access to a few thousand web sites.
I suppose the argument is you're building a house without a door. While you may believe you have everything you will ever need in that house, there's a likelyhood you will eventually need to leave (or something needs to arrive). Now you're stuck. Of course, it's not all or nothihng when it comes to IP space.
If you were going to use 11.x for an air gapped secure enclave, I would have a very difficult time presenting a scenario where that may bite you later. However, I'd vote to use CGNAT reserved space before any 'unused' public IP space.
This is useful threat intel as well b/c many firms employ source ip address in policy constraints and log monitoring. However it's trivial to masquerade as a target IP address range in a private vpc, and overlap could indicate that someone is up to some tomfoolery.
(FWIW cloudtrail will include source vpc and/or vpc endpoint information when the request is coming through an endpoint. This will help detect those requests)
I believe the networking term is "bogon". Basically you're using space in a way that isn't intended. Mostly I've seen it as people trying to use RFC1918 space on public networks probably because of misconfigurations and most routers/FWs will ignore these. This is sort of the inverse.
Not really, bogon is generally used for either unallocated space or "Martian" packets (packets with a source in private space). This space is unannounced, but not unallocated, therefore it doesn't show up on the bogon list.
Yes I didn’t understand this as squatting and made me question if I understood the post. As it is a topic I admit to not being too deeply knowledgeable about.
I think in general the author's definition of squatting is reasonable. I see it to mean "living on land you don't own" or more directly "using IP addresses that you don't own".
My point is about fully private networks that aren't connected to the internet. I would argue that in this case you do own all of the addresses, even if someone else owns them on the public internet.
The author is only talking about private networks. This does however occasionally happen on the public internet (or when a government turns their country into a private network and does this maliciously). The most common source is "BGP Leaks" which is a fun search.
My favorite example is when a Turkish ISP accidentally declared themselves to be the best route to anywhere, and the whole Internet simply took their word for it.
That's like saying if I create a 3D model of my neighbour's car and drive it around the streets of a videogame I am "squatting my neighbour's car" or "using a car I don't own".
A couple of years ago Amazon bought four million ip addresses for $108 million dollars. 44.192.0.0/10
AMPRnet sold them a quarter of the ip addresses that were allocated for amateur radio. They got a /8 back in the 1980s. A small number of addresses were used for ham radio networks but the AMPRnet addresses were generally not routed between the internet and the radio networks.
In the US it's hard for many home users to get static allocations of IPv6 but you can easily get an IPv4 block for $10/month or whatever. So same issue, if you need IPv6 static then you have to go to very expensive service tiers given the "shortage" of ipv6. Reality is I think IPv6 is just a pain up and down to deal with and they haven't sorted out all the tooling to deal with it for static IPs.
I know a naughty person who decades ago hijacked a /8 IPV4 network block when the company that owned it went out of business, by registering their expired domain name and sending in an email from that domain, transferring ownership of the block to himself.
It was "hot" so he couldn't just squat on it or sell it in the open, but he laundered it by trading it to some shady company in exchange for free network services for life.
If I were him, I would have printed out all the addresses on little slips of paper and taken an "IPV4 Address Bath" like Huell's scene in Breaking Bad:
Yep, it was a long time ago, and he was one of those "old net boys" who worked on the early ARPANET, but I won't say anything else that might identify him.
I have another naughty friend (not the same person) who worked at SRI-NIC implementing and maintaining the ARPANET TACACS database, and as a personal favor, he created our mutual friend Devon his own ARPANET TAC card.
So Devon's free vanity TACACS account was named "DEVON", while most other accounts like mine were something ugly like "DH32", using initials and numbers. One day his boss summoned him to his office and showed him a print-out of the TACACS accounts, with "DEVON" right at the top, and asked him who the hell that was. He sheepishly prevaricated that "DEVON" was actually a control code to turn the printer DEVice ON, which accidentally got printed at the beginning of the list because of a bug in his program missing an escape code, and he would fix it right away. And that's how Devon lost his TAC card. We still tease him about his name as a printer control code, and call him "DEVOFF" when he talks too much. I'm pretty sure his boss knew what was up, but just let it slide.
Network security was a lot different in those days. TAC cards only happened later when they finally put passwords on the dialup TACs/TIPs -- you originally could dial up and connect to any host on the ARPANET without a password, then you could ask nicely for a free tourist account at places like the MIT-AI Lab. It didn't even require any social engineering, just being polite and curious, reading documentation, and following instructions.
I asked BBN nicely about the TIP manual, and they helpfully mailed me a free hardcopy of the "Users Guide for the Terminal IMP", which documented how to take control of other people's sessions and even divert their output by prefixing @ commands by their terminal number! See "Section 5: Unusual uses of the TIP" page 5-7, "Setting Another Terminal's Parameters" and "The DIVERT OUTPUT Command":
The guy who originally wrote that TIP manual in 1971 was none other than Will Crowther, who also developed Colossal Cave Adventure with Don Woods! You're in a twisty little maze of IMPs, all different.
ARPANET Psiber SPACE (circa 1986): This is the network of IMPs (Interface Message Processors) that comprised the ARPANET in 1986. The ARPANET is history now, but thanks to the magic of Pseudo-Scientific Visualization and the ScriptX language and class library from Kaleida Labs, you can now experience what it was like to be free ranging packet hopping around the ARPANET in 1986!
Keith mentions that ARPANET TACACS passwords were installed in 1986, and even mentions how Jerry Pournelle got himself kicked off the ARPANET for being obnoxious in 1985, which I can conform with the email messages he mentioned. The first message is about TACACS, and explains how MILNET TACACS was implemented in 1984, before ARPANET TACACS (in 1986). It was addressed to the same DEVON, and HN's own GUMBY chimed in with some salty remarks:
The "Arpanet" episode of The Americans featured a classic scene with an academic computer science professor dude bullshitting about the ARPANET -- I'm sure we both know somebody exactly like that from that period, who made eloquent hand-waving metaphors about Virtual Spaces and Post Offices and God and Disembodied Brains, trying to explain to skeptical people how vast and important the ARPANET was (with its 8 enormous bits of address space). But he kinda had a point, calling the PDP-10 "The Beast".
But the thing The Americans "Arpanet" episode got wrong is that you didn't actually have to slap on a Frank Zappa Soul Patch and a Beatnik Wig, dress up like a janitor, and brutally murder an unlucky grad student to get on the ARPANET, you just had to ask the right people nicely! (But it's still one of the best episodes, with the scene about passing a lie detector test by clenching your anus.)
IPv4 address space is in short supply, so some people decide to use IP space ( allocated, but not advertised) that doesn't belong to them. The consequences are pretty well described in the article you quote.
But this address space is non-routable, so it's effectively using address space that's equivalent to a 10/8 or 172/12 or 192.168/16 address. There's no need to grab random /8s when there is plenty of IPv4 address space that won't ever get routed to the internet (assuming nobody does something as dumb as actually changing the 127/8 semantics). If they somehow run out of those, 100.64/10 is also pretty much guaranteed not to be reachable from the internet.
I have an old static IP from the days of running a server from my bedroom. My mom kept it after I moved out. Stopped responding to pings 2 or 3 years ago when she upgraded her internet package and the ISP didn’t honor our ”Hey we have a static IP” agreement.
There is still plenty of IPv4 space available, it's just very badly distributed, for instance, due to early limits in Cisco's IOS, Chevron acquired an insane 26 Class B address blocks when connecting to the net back in the early 90s! With CIDR, we can easily reuse the many unused addrs like those, but the pain of readdressing has their owners sitting on them, raising prices and making them even more reluctant to turn loose of any for fear they won't be able to get them back...
And, let's face it, IPv6 addressing is so fundamentally horked-up that it's practically only usable by propellerheads in the cloud backend: First, the addresses are too damn long and unwieldy to really be used; and second, even most people reading this, tech people in a tech forum, struggle to really grasp the inane IPv6 address shortening rules! Like X.400 mail addresses, they work technically, but are unusable in practice.
(For those of you fortunate enough not to remember, the best way to get and transfer someone's X.400 address, even within the X.400 network, was to have them mail someone through an internet gateway and use whatever it said. Marshall Rose devoted an entire chapter to ranting about this in his Internet Mail book...)
> First, the addresses are too damn long and unwieldy to really be used
How so? The network-prefix portion of IPv6 is 64 bits, which is a pretty conservative extension of ipv4. Everything after that is under the control of end users, so nothing's stopping them from manually assigning simple ::1, ::2 etc. values for the host identifier part - or whatever addressing scheme happens to be most convenient for any given application.
> First, the addresses are too damn long and unwieldy to really be used; and second, even most people reading this, tech people in a tech forum, struggle to really grasp the inane IPv6 address shortening rules!
I have been using IPv6 for at least twelve years and I will agree that at first - maybe the first six months or year - I found these things confusing. But I think your assertion is based on lack of familiarity. Fundamentally, IPv6 works well, and just needs some open-minded people to spend time with it.
Remembering and hand manipulating IPv6 addresses is not something end users need to deal with.
Like everyone else on my ISP, I have a publicly routeable v6 subnet at home and v6 addresses on my phones. I couldn't tell you what they are, but they work just fine.
> Remembering and hand manipulating IPv6 addresses is not something end users need to deal with.
Assuming it's configured correctly. Most devices are not.
> Like everyone else on my ISP, I have a publicly routeable v6 subnet at home and v6 addresses on my phones. I couldn't tell you what they are, but they work just fine.
Why would you ever want publicly routable addresses on devices inside your home?
If Ipv6 was simply a 64-bit quad improvement on IPv4 it would be fine. However, the only valid use cases I can think of are mostly to the benefit of end users.
What possible need could anyone have for more address space than the non-routable private address blocks already afforded by IPv4? Throw in the insecure-by-default and frequent misconfiguration out-of-the-box and you have the current flaming security dumpster fire that is IPv6.
> Assuming it's configured correctly. Most devices are not.
Aren't they? I've never seen a home user fight with IPv6
> Why would you ever want publicly routable addresses on devices inside your home?
Because that's how the internet is supposed to work. It's what protocols are designed for. IPv4's shortcomings have led to many stupid security issues (SIP ALG, FTP ALG, all the other ALGs, all allowing anyone website to punch a hole straight through consumer firewalls). I don't know what insecure-by-default devices you use, but all routers I've seen come with a firewall enabled by default set to deny all incoming traffic.
If you don't want that for some reason, feel free to NAT66 your network into your own chosen ULA.
IPv6 is no more of a flaming security dumpster fire than IPv4.
> First, the addresses are too damn long and unwieldy to really be used; and second, even most people reading this, tech people in a tech forum, struggle to really grasp the inane IPv6 address shortening rules!
I don't know about everyone else, but when I want to go to Hacker News I go to https://209.216.230.240 and ignore the security warnings of mismatched name. Way easier to remember than news.ycombinator.com, its five fewer characters!
I am a little ashamed to admit this, but I can't remember the URL for Hacker News and always have to search for it in Google if I am on a device that doesn't have it bookmarked. Somehow I still remember other long URL's like http://altavista.digital.com though.
I know a number of IPv6 activists that are hoarding IPv4 address space with that in mind. Market forces will eventually provide compelling incentives once we have exhausted the easily accessible types of CGN magic.
I had an ASSIGNED PORTABLE /24 in my name back in the 90s. I don’t have many regrets in life, but returning that to the registry remains a real big one.
This. I have a few /24s and only actually use maybe 25 active IP addresses. If I want to exist in global BGP tables, it's the smallest block I can use for my ASN (and not be filtered out). I think in 2022, the rise of SDWAN, CDNs, and, Zero-Trust reverse proxy services, it's not actually relevant to roll your own BGP, unless you're a big player, or if you just want to fly solo on the Internet.
> At the time of writing the market price for an IPv4 address is around 50 USD
That's quite an outperforming asset class if true [0].
For a point of comparison, Microsoft paid $11 per address in 2011[1]. To get to $50 is about 15% appreciation/year, plus the added benefit of being able to rent them out by the minute. This article estimates that Amazon has paid about $25 per address in recent years [2].
My old uni holds two /16s which are used for clients. Firewalled, but if you use the Wi-Fi there then you are getting your own "personal" IPv4 address per device.
I know several universities that do the same. On certain LANs there isn't even a firewall, you just get a public IP. At my current university I think there's a limit of five or six static allocations per person, the rest is all dynamically allocated (and still a normal IP, no NAT here).
And I honestly don't see why not. This is how the internet was designed to be used, and it works a lot better than most large managed networks in the 10/8 range I've seen. It'll only be a problem once there are more students and services than there is address space.
You mean they are using IP's as they were originally designed? Those people probably have NO conflicts or problems with things like video conferencing, VPN's, etc.
BenJojo sings “I’ve got too much…time on my hands”
The whole migration to IPv6 reminds me of DECnet migration to OSI…which basically never truly happened (because XNS/ITP grew up and became TCP/IP which was then extended to the edge with PPP/RAS, ending the era of store-and-forward email/usenet and destroying X.25/X.PC with its distance-based pricing, heralding the new era of free SPAM and Script Kiddies From Overseas). Same thing will happen to TCP/IP..something else will succeed it before IPv4 is obsolete, probably after somethingBad(TM) happens to create the market imperative for network operators to invest in the alternative.
Well, I’m entirely willing to believe the US DoD is one of the few entities that have more than 2^23 computers they want to be mutually addressable, so the RFC 1918 space is just too small for them if they are to run IPv4.
DoD has 8 million computers? It's not like it's all government branches combined.
In fact - DoD should just have it's own internet - that is completely separate. I'd argue that DoD networks should not have any connectivity with broader internet, making their use of the whole 32 bit space completely independent from everyone else.
That means that no DoD computer can be connected to both at the same time. Which is a reasonable thing to have.
Doesn't mean that DoD cannot use the global internet, just not use it and their own at the same time. I mean... They could even send traffic over global lines, without taking up IP addresses.
The author of trilema.com at some point boasted of having bought a /16 and then renting it out.
Something I don't quite understand is why IPV6 is better, if anything sticking to IPV4 will lead to more "selective" use. Actually useful things get an IP, the rest, well, better get more useful
I work at hp and we have all of 15.x.x.x and use it for all our internal networking. At one time we also had all of 16.x.x.x because of DEC/Compaq. I suppose at some point this could be an asset for us since we could use some different scheme internally.
I don't understand why was the next version of IP not just identical to IPv4 but with more bits in address space? Were they trying to do too many things at once in the 90's?
I don't think it not being that harms it as much as people think. It has to require updates for everything either way, people by and large don't care about "oh but it's only a small total breakage, going to jump on that then". On the other hand, yes, there certainly was some "we break everything anyways, so lets 'improve' things", combined with those improvements being designed at the wrong time, with assumptions that not always turned out to match reality. (E.g. a bunch of pieces that were added to IPv6 kind of assumed that routers would stay as they were, with routing done on CPUs, in software. Which they obviously didn't, and specialized hardware works on entirely different constraints)
It was fixing (or trying to) issues with the v4 spec that were now very apparent.
For example, ipv4 technically has a link-local address space but barely anything will use it and even less will successfully. Many other 80/90s protocols did much better at that (IPX being an example) as well as having distributed name and service locators and such.
IPv6 local networks of IoT devices or whatever can pretty much automagically start communicating with zero configuration to anything else locally. No DHCP or whatever required.
The world didn't stand still between v4 and v6, it'd be weird if the protocol did.
There still hasn't been a coherent answer. The best approximation is that a lot of networking researchers saw their once-in-a-lifetime opportunity to bikeshed the lowest layer of the public network stack, and couldn't resist the urge.
All of this could have been avoided by making NAT64 part of the original IPv6 standard (instead of wasting a decade pretending like it wasn't necessary) and making it a mandatory service provided by every IPv6 router, unless all downstream routers already provide the service. This would have forced an invisible-to-endpoints IPv6 transition, starting at the backbone ("no default route" region). Carriers would have very quickly pushed the NAT requirement downstream (away from the default-free region) in order to offload the burden it creates. Each step of the transition would have been a strictly local change between two peers, one of which is paying the other, and can therefore can be incentivized ("hey, if you run NAT64 for your downstreams so we don't have to, we will charge you less per month"). No global coordination, and the local coordination is always across a commercial relationship where a carrot can be dangled.
But instead we got what is basically a flag day, so "the transition" will never ever happen. We'll still be talking about it in twenty more years.
IPv6 is pretty much IPv4 with more bits - at least compared to the alternative of the time that was CLNP/DECNet (which had 20byte addresses and is quite different).
And the very slow transition hasn't really anything to do with the standard itself, but with the transition technologies (NAT64 like you mentioned).
It would have happened with any of the proposed alternatives. Hindsight and all..
NAT itself wasn't even a thing yet (not an RFC anyway) when IPv6 was being developed.
Flag days had worked in the past too, so why not again?
You'd need to buy and have transferred a /24 (256) or more of "legacy" IPv4 that was allocated by IANA prior to the RIR system for your region. Then you could either convince your provider to route that block on your behalf or get an ASN and BGP peer at your local IX (or even over a tunnel to one). Getting it transferred to you may require setting up a business depending on your RIR.
All in all you could make the above happen for about the price of a lower end new car in the best case.
There are other ways to get non-legacy IPv4 assignments now but those are leased not owned.
Use it or Lose it. Back in the day companies were allocated large blocs of IP space. They do not own it - what they do not use should be allocated to others who will use it with zero compensation to squatters - they own nothing. Sadly some have valued the IP blocs as assets = boosted bottom line - and there are some large boosts! These people will whine and scream - but screw them, they are just squatters and deserve nothing.
Valid users can easily be identified by network data.
Could only be applied to more recently allocated networks and they are already paying some sum per network per year (not that much depending on the region but a non-zero number).
However the worst offenders are legacy space that predate the modern RIR system and would be completely unaffected by this, since there is no mechanism to charge them.
The author of trilema.com at some point boasted of having bought a /16 and then renting it out.
Something I don't quite understand is why IPV6 is assumed to be better, if anything sticking to IPV4 will lead to more "selective" use. Actually useful things get an IP, the rest, well, better get more useful? Wishful thinking?
> if anything sticking to IPV4 will lead to more "selective" use.
That's a scarcity mindset and isn't useful in this case.
Who cares if "low" value things use the internet? Imagine a network in rural Africa. It can't pay market rates for IP addresses but would be extremely valuable for its users.
IP addresses aren't a negative externality like pollution or traffic, they're an artificial construct. So restricting them doesn't actually help people, and making them abundant is a huge benefit to literally everyone.
That's a rather optimistic view of the situation. The next member who will get a block has already been waiting for 2 months and it's unclear when they will get one. It stands to reason that members applying now wold have to wait (potentially significantly) more than 2 months.