Posted
by
Soulskillon Friday December 17, 2010 @07:28PM
from the routed-into-a-corner dept.

Julie188 writes "As public IPv4 addresses dwindle and carriers roll out IPv6, a new problem has surfaced. We have to move through a gray phase where the only new globally routable addresses we can get are IPv6, but most public content we want to reach is still IPv4. Multiple-layers of NAT will be required to sustain the Internet for that time, perhaps for years. But use of Large Scale NAT (LSN) systems by service providers will cause problems for many applications and one of them is reputation filtering. Many security filtering systems use lists of public IPv4 addresses to identify 'undesirable' hosts on the Internet. As more ISPs deploy LSN systems, the effectiveness of these IPv4 filtering systems will be hurt."

Because when one of our university email account gets hacked and starts spamming, other providers block our SMTP server, effectively knocking out communications between us and that ISP. NATing wouldn't change that, unless spammers use their own SMTP server behind a NAT router.

All that's required is a more creative solution to prevent spamming. Only one of many system may become problematic with ipv6. That's all. I'm looking forward to having my fridge order groceries automatically when we're about to run out.

Actually, we will just ban or greatly increase the spam score of anything coming from these NAT pools just like we do today with dialup and consumer broadband IP pools today. People with real servers will continue to have dedicated IP addresses that aren't behind these NAT pools and so we will judge them individually based on reputation (or lack thereof).

It is interesting that even now we are still using Simple Mail Transfer Protocol. With spam, phishing etc, maybe it is time to replace SMTP by either a plain Mail Transfer Protocol or even a Complex Mail Transfer Protocol.

More to the point, SMTP hosts will be pretty much forced to do something more productive than blocking via IP, which amounts to group punishment. (Something apparently only tolerated on the internet).

Not really. By the time you're talking about LSN/CGN, you're talking about customers that send mail via their ISP's mailserver, not directly. Business customers wanting to send mail direct to the Internet without worrying about NAT making "their" IP look worse, will undoubtedly be able to buy a non-NATted IP.

That solves it for email, but think of the trolling concerns. Forums, wikis and IRC channels would no longer be able to ban individuals by IP address, only massive blocks of translated addresses. Just imagine Wikipedia getting persistantly trolled by one person vandalising pages, and having no way to stop it short of banning every Comcast customer in a major city.

SMTP needs a ground up re-write, and it will need it just as much (if not more) after IPV6 is deployed.

SMTP isn't the problem and is not in need of a ground up rewrite. The problem is social, between spammers and suckers, their victims. As has been shown via NNTP, instant messaging, and Facebook spam et al, there is no technology immune to spam. Spam will be with us as long as suckers exist, and there are people willing to exploit those suckers. Yes, basically for eternity.

There will start to be IPv6 dnsbls and mail OPs will start keeping IPv6 local block lists. It's the same old game with a new numberi

IP filtering has always been useless from a security standpoint. Same goes for MAC address filtering.

Anyone anywhere can change both easily. Blocking addresses is only a matter of convenience.

This "news" just means that tons of "security" software and filtering hardware (Barricuda, anyone?), is being exposed as the useless, inflexible crap that they are, and the companies behind them are trying to point fingers at large network operators while simultaneously touting their next version, which will have IPv

IP filtering has always been useless from a security standpoint. Same goes for MAC address filtering. Anyone anywhere can change both easily

Unless you have unfiltered BGP access to a major backbone, you have no hope of conducting a real conversation over the Internet using someone else's IP address, because the return packets will be routed back to them, not to you.

IP filtering has always been useless from a security standpoint. Same goes for MAC address filtering.

Anyone anywhere can change both easily. Blocking addresses is only a matter of convenience.

Foolproof? No. Useless? Hardly.

Locks on your front door are useless. You can buy a hammer really cheap from, well, pretty much anywhere. The fact that windows exist, however, does not diminish the fact that door locks provide a very important layer of security - just as IP filtering does.

Bad analogy is bad.

Blocking an IP or a MAC address is completely pointless. It requires less than 5 seconds of effort to get a new one. There are no windows or hammers involved. You simply walk right in the front door because it will be unlocked when you say "My name is... Mr. Snrub.".

Depends on the ISP. If it's dialup, you can usually just reconnect. DSL, trickier. Cable, I find it is associated with the MAC address of the device connected to the modem. Release DHCP, change MAC, get new lease... takes about five seconds if you script it.

I still think the best way to handle this would have been by high bit extension in each octet field.

Yeah, I know, the theoretical non-constant numeric address length would have been a serious pain to predict the hardware for back in the '80s, when (ergo, I wish) they might have had the foresight to reserve the high bits at each level for possible other uses.

But it would have been nice if an ISP could have, by definition, its own extendable address space to allocate out of, and any customer could further ext

end user customer networks (the ones most likely to go this route) are already on various "mail shouldn't be coming from here" blacklists, and those customers also should be already using the isp's mail servers for outgoing mail. it's a small incremental step, nothing more. Those running servers will necessarily get unique addresses and not be affected by reputable blacklists that are correctable.

end user customer networks (the ones most likely to go this route) are already on various "mail shouldn't be coming from here" blacklists, and those customers also should be already using the isp's mail servers for outgoing mail.

I assume you're talking about end users connecting on port 25 (MTA-to-MTA communication), not port 587 (MSA-to-MTA). Otherwise, what should people do when the monopoly broadband ISP has unreliable mail servers, or when they're using mail on a laptop temporarily connected to an ISP other than their own?

authenticated mail (which can be done on port 25, it doesn't have to be 587, but should be these days because of port 25 filtering) is not normally subjected to blacklist filtering, and is thus not affected.

The vast majority of people don't run their own mail servers though, so their mail clients are configured to use their isp's mail server. Again, not affected.

If your isp has unreliable mail service, then find another one --- there is no shortage of options there. For practical purposes, in that case, y

authenticated mail (which can be done on port 25, it doesn't have to be 587, but should be these days because of port 25 filtering) is not normally subjected to blacklist filtering

Authenticated mail on port 25 is subject to port 25 blocks by those ISPs that don't deep-packet-inspect to distinguish unauthenticated SMTP from authenticated SMTP (RFC 2554) or encrypted SMTP (RFC 2487). But I guess ISPs are far less likely to block 465 or 587.

If your isp has unreliable mail service, then find another one --- there is no shortage of options there.

Find another what? Did you mean find another mail service, aka a "smarthost"? That's difficult if your ISP blocks the ports that smarthosts use. Find another ISP? In a lot of cases, it's either the one broadband ISP in your area or dial-up.

I work for an IP reputation company (and am not representing it in this post).

This is not a complicated issue. The LSN portals will merely have to add a tracking header to all mail they process (and block anonymous direct mail if they want to escape DNSBLs' wrath). This is already an issue with webmail (e.g. Google doesn't add the tracking header, so it's MUCH harder to trap spam originating through GMail than it is through providers like Hotmail who do provide this extra tracker).

The headers aren't spoofed. When you use Hotmail or Yahoo, your IP is added to a tracking header by the webmail server so that IP reputation systems can pass along the blame as if it were a Received: header (there's more to it than that, but this should give you the principle). Since GMail doesn't do that, there's nothing to be done; the tracking can't go beyond Google's servers.

If a spammer spoofs headers so as to pretend to pass blame on, the trust [apache.org] doesn't extend far enough; the relay used by the spammer to add those fake headers isn't trusted and so the buck stops there. When dealing with real webmail providers, the trust can be extended to the established webmail relays and then followed into the IP tracking header.

We have meandered a bit off topic here... my point is that this is possible for the nearly identical problem of webmail, so somebody merely needs to figure out how to do it for the IPv6->IPv4 routing process. The simplest solution is the one I outlined above; require a mail relay that speaks both protocols so it can properly record the conversion with a Received header. Modern IP reputation systems (and the clients that poll them) are fully IPv6-ready and will process this perfectly.

So what you're saying is that Google has decided to fully claim reputation-ownership of the mail their users are sending. They're staking their reputation that their users don't generally spam. If it was a big enough problem you would blackhole all of gmail, right now you're upset because due to the large volume that gmail sends, any percentage of spam is a problem.

I don't mean to attack or defend anyone here, just curious.

I think the deal is just that anything that comes through gmail needs a more heuristi

Yes, it's working. It is in Google's interest for gmail accounts to have less spam than other email accounts. Aggressively filtering incoming email and not caring if their users are sending spam (unless they are sending it to other gmail users) helps this.

Is a captcha not enough of a barrier? I've never seen a website that actually banned @gmail addresses. I'm curious, and highly surprised.

The phpBB version 2 Captchas are broken, they are automatically identified by bots. I checked on the new version of phpBB and #1 I don't like the new features and #2 a new Captcha system was still being perfected.

I have posted through the years on Captcha and the phpBB is trivially simple but there are others on other sites that are so non-trivial I quite frankly can't rea

It's a vague term. I've seen it before, but it can mean anything from a company that gets mistakes removed from IP blacklists (usually a consequence of a computer being compromised - once it's resecured, the blacklists need fixing too) to companies hired to manipulate google rankings, submit glowing product reviews to shopping sites and threaten critics with legal action. Just a very vague description

It's not just spammers. A lot of on-line games, for instance, record the IP address used to log in to a game in the account's history. Customer Support then uses that to help determine eg. whether a claim of a hacked account is valid or bogus. Large-scale NAT is going to mess with that by confusing the record: one computer may appear to be using a different IP address for each login, and multiple unrelated computers can appear to have the same IP address. And with a lot of games moving towards RMT, a hacked account can mean the loss of real money for the player. When CS tells that player "Sorry, the login where the items were sold/transferred came from one of the IP addresses you normally log in from, the problem's on your end." and the player learns that that's because his ISP is NATing their entire network, he's not going to be happy.

and the player learns that that's because his ISP is NATing their entire network, he's not going to be happy.

</reality>... and he goes to forums where such things are discussed and finds out that other users are using IPv6 and don't have problems like that and asks his ISP why they don't support IPv6. The ISP listens to their customers and makes rolling out IPv6 their #1 priority. IPv6 gets everywhere, world peace is finally achieved, and we enter a golden age of the internet.<reality>

Easy enough solution to that. Just run a local 4to6 NAT. You can do SNAT from as many v4 192 addresses as you need to translate to the 6 hosts you want to connect to remotely. Then just use the 192 address in your app. It will be an extra step and you might have to set up the NAT on both the client and the server but it should work.

It's not just spammers. A lot of on-line games, for instance, record the IP address used to log in to a game in the account's history. Customer Support then uses that to help determine eg. whether a claim of a hacked account is valid or bogus. Large-scale NAT is going to mess with that by confusing the record: one computer may appear to be using a different IP address for each login, and multiple unrelated computers can appear to have the same IP address. And with a lot of games moving towards RMT, a hacked account can mean the loss of real money for the player. When CS tells that player "Sorry, the login where the items were sold/transferred came from one of the IP addresses you normally log in from, the problem's on your end." and the player learns that that's because his ISP is NATing their entire network, he's not going to be happy.

I'm not sure what the likelihood of the hacker winding up behind the same NAT as you is going to be. Generally the hackers will be in a different country from you. So while this may have the potential to cause that problem I think they will be very few and far between.

When CS tells that player "Sorry, the login where the items were sold/transferred came from one of the IP addresses you normally log in from, the problem's on your end." and the player learns that that's because his ISP is NATing their entire network, he's not going to be happy.

I understand the point you are trying to make, and I agree with you. I just have to be pedantic and point out that currently, for WoW accounts that have been tampered with, it doesn't matter that the activity was on the same IP address.

If it did matter, there would be a lot of guys with neglected girlfriends that would be unable to get their characters restored.

When CS tells that player "Sorry, the login where the items were sold/transferred came from one of the IP addresses you normally log in from, the problem's on your end." and the player learns that that's because his ISP is NATing their entire network, he's not going to be happy.

Further missing the point: the NAT referenced here isn't the kind of NAT that you are thinking, between an IPV4 public address (EG: 208.39.22.13) and a non-routable IPV4 address. (EG: 192.168.1.19)

The NAT being referenced here is between IPV4 (which doesn't understand IPV6 address space) and IPV6. All connections coming from an IPV4 address to an IPV6 address will have to involve NAT, where the ISP has a NAT gateway so that internally hosted IPV6 addresses initiate connections through NAT to the IPV4 networ

and blizzard is already adressing this problem through the use of 2nd channel Authentication. If you've got a Blizzard account, simply spend the $7.00 U.S and buy their stand-alone authenticator and configure your account to use it. Problem solved and cheaply at that.

So, why not just have a public database of LSNs and have them run extended ident service? (I.e., you supply it with local-remote port pair and it will tell you the IPv6 address of the NAT'd peer. Then you just use that for the peer identification from then on.)

Seriously, IPv6 is there to replace IPv4. Tell everyone who whines 'tough shit' switch over already. If I have to pay an extra 5 dollars a month for a year to my ISP for that to happen then I would. Just stop trying to extend the life of IPv4 when there is a suitable replacement already available.

Seriously, IPv6 is there to replace IPv4. Tell everyone who whines 'tough shit' switch over already.

Are you trying to create the massive failures we were supposed to have for Y2K? IPv6 compliance is a rather low priorities for most companies and is not being taken seriously to the level that Y2K was. You're asking for a lot of "tough shit" to come your way even if you and your immediate provider are fully IPv6-compliant.

If I have to pay an extra 5 dollars a month for a year to my ISP for that to happen then I would. Just stop trying to extend the life of IPv4 when there is a suitable replacement already available.

You want to pay $5/mo in order to stick it to those who don't think like you? This is a capitalist system -- use it: discount customers five dollars a month to be stuck without IPv4

Having been intimately involved with spammers over the years I can say that this change will only escalate the ongoing game of use / burn / blacklist / move on. Yes, more poor commercial entities will unknowingly and unwillingly have to call in Wally the IT guy to help them get off some blacklist somewhere so their mail will flow, but in the grand scheme this will not change the processing power of the mail bots or tilt the scales in a significant manor. IMHO.

I'm beginning to think there's only one way to stop email spam. Develop some new flashy service that "replaces" email. Then get everyone who is stupid enouh to fall for aPhish or to answer a UCE to switch to this new-fangled fad. Then once only people smart enough to never reply to spam are using email, there will be no motivation to spam.

Legitimate mail servers will still need an IP address, whether that is IPv4 or IPv6. Their outbound SMTP connections can just use that same IP address. The real issue involves all those end user (broadband and dialup) IP addresses, which more and more will be multiple users sharing them for outbound connections, with no inbound. Make those have zero reputation. Let the IP addresses which are associated with real mail servers have the reputation earned by its behavior.

One big difficulty will be mail servers stuck only on IPv6 trying to deliver mail to those on IPv4, and visa-versa. But this is at least a substantial subset of the IP space. That means it can hold out for a while on IPv4, until enough IPv6 is deployed to make a "mad rush to IPv6 for email" can happen. But in the mean time, those who can do mail exchange between servers on IPv6 will be pretty much spam free, for at least a while. When spammers get on IPv6, then we know IPv6 is "happening".

To encourage IPv6, those who are on it can do things like adding extra goodies to IPv6 users. I do know a lot of porn is already there. Maybe extra features on web sites can be made to work on IPv6, too.

Maybe as all mail behind NATs get blocked by spam filters the network administrators will actually start blocking mail from infected hosts in their network so that legit mail is accepted again. Wishful thinking?

As more ISPs deploy LSN systems, the effectiveness of these IPv4 filtering systems will be hurt.

That doesn't follow. The folks in dynamic space (the same space that will be served by LSNs) are already considered spammers when they connect to a non-local SMTP server. The only reason they're scored instead of outright blocked is that there's no rigorous list of what is and isn't a dynamic space. It makes no difference to the server whether it filters a range of IPs or a single IP.

Identifying the individual spammer from an abuse report is slightly more difficult, but only slightly. And if you're behaving like a good net citizen, you probably blocked outbound 25 at the LSN box to begin with so you're not getting any reports because your virus-laden customers aren't able to successfully spam.

If your mail server supports IPv6, the mail will go sender's client to sender's MTA to your MTA, all via IPv6, with full headers.
So the problem only affects recipients who are slow getting their mail servers IPv6 enabled, who force senders to reroute their mail through an IPv6 to IPv4 gateway.
So seems to me it's a good reason to hurry up and get your servers on IPv6.

You shouldn't be running a "server" at home anyways. The internet was created so that you could buy services from large companies like your ISP. Running your own server at home is socialist. Think of the children!

Many IT professionals including myself feel that IPv6 is a joke and is unnecessary in most practical scenarios. Arguments I tend to throw out on face value are "why not IPv6?" and "we're running out of IPv4 addresses". Keep NAT'ing IPv4 until the cows come home - no one except tech geeks will really care if we do.

The biggest problem with everyone staying on ipv4 and natting until the cows come home (which will be never... these cows will *not* come home for ipv4) is that all of a sudden you have thousands, millions of end-users on nat going through overloaded 4 to 6 proxies.

And if no one switches to v6, only rich content providers will be able to afford direct ipv4And then, due to the fact that end users will certainly not have a public ip address:- streaming media of any kind will eventually be unusable due to over

Many security filtering systems use lists of public IPv4 addresses to identify 'undesirable' hosts on the Internet. As more ISPs deploy LSN systems, the effectiveness of these IPv4 filtering systems will be hurt."

In other words, as IPv4 dies, using IPv4 for stuff won't work as well.

Using an IP address to determine the content of a message is a bad idea anyway.It's like determining what cars are carrying drugs by looking at the license plates, and then punishing the car dealer for selling the car.

-1 for not even remotely knowing what you're talking about.
But anyway, IPv6 is essentially the same thing as using a longer name. Instead of having only 2^32 addresses, IPv6 has 2^128 addresses. Enough to give every man woman and child on earth a trillion permanent addresses a year for 4.85*10^16 years. (caveat: assuming the population will stay at 7 billion people for 4.85*10^16 years)

While what you say is true, what you and the other "just switch to IPV6 already" folks seem to be missing out on is if everyone was to switch at noon tomorrow in all likelihood you would be looking at MASSIVE outages, which would go on for weeks if not months. Why? Multiple reasons:

One, thanks to offshoring IT has been a dying field for quite awhile now, with fewer and fewer new blood coming in. What that means is in the flyover states you have most if not all the backbones being run by old guys who haven't kept up on the tech, and from the ones I've talked to most are looking to get out of IT if at all possible. That means the experience just isn't there, it isn't gonna be there, and many will take early retirement or just get out rather than deal with the IPV6 mess. That in turn means things that take minutes to fix in IPV4 will take days in IPV6 simply because nobody knows how to use the new tools.

Two: Infrastructure. There is a hell of a lot of VERY expensive equipment out there that either cannot be upgraded to IPV4, or could be but is no longer "supported" by the OEM, which means a MASSIVE amount of money will have to be spent in a dead economy. Now considering these cableco/teleco duopoly sure as hell ain't gonna take a CEO pay cut, that either means pay for it by gouging the customers even deeper, which in most flyover areas Internet usage is declining thanks to price gouging, or make it up by screwing the workers even harder, which results in number one above. Then add in the fact a good 90%+ of the routers and firewalls and other network devices in consumer homes WILL NOT support IPV6, and in fact most of the routers sold today STILL DON'T support IPv6 and the ones that do are triple price compared to the others, means you are talking MASSIVE amount of eWaste is about to be hitting the environment. You are talking truckloads of routers, modems, all having to be shitcanned. Again this will raise cost that the consumer WILL get stuck with in a dead economy.

So you see, there is a damned good reason that they are gonna string along IPV4 for every last second they can. They will do so because it is gonna be a massive clusterfuck when the switchover comes, with complaining customers because NOTHING in their house works, no IT guys with experience enough to fix even the simplest of problems, and warehouses worth of gear, both dirt cheap and ridiculously expensive, all having to be taken straight to the dump. Frankly it is NOT gonna be pretty, not at all.

While what you say is true, what you and the other "just switch to IPV6 already" folks seem to be missing out on is if everyone was to switch at noon tomorrow in all likelihood you would be looking at MASSIVE outages, which would go on for weeks if not months.

Network addressing is hierarchical, so we will probably be running out of IPv6 addresses long before ~2^48 subnets are allocated. Of course that is still a few trillion.

You couldn't make a router big enough to process 2^48 subnets (let alone 2^64) directly. The hierarchy is necessary, and hierarchy means lots of "wasted" address space. To say nothing of the fact that the right most 2^64 bits of each IPv6 address aren't really routable at all - not without playing games at any rate.

NAT is fine for people who only make outgoing connections; i.e. the passive internet consumer.It's hell for the rest of us, but hey, since when did the massive media conglomerates ever have the techies' interests at heart?

NAT is fine for people who only make outgoing connections; i.e. the passive internet consumer.

Unless the passive internet consumer uses P2P software, or VoIP (from a provider which is not their ISP), which is harder with NAT and probably requires active participation from the ISP to make it work. The RIAA might have a few things to say about that.

If you meant "What if all the players fall in the first category?", then that's a non-problem. In that scenario, everybody has IPv6 access, so they'll have no problem talking over that.

If you meant "Isn't there another category where players have a NATed IPv4 address and no IPv6 address?", then that's unlikely. NATing IPv4 addresses is a transitional technique, so it doesn't make much sense to do that until you support IPv6.

Techie: We can't grow the network any longer! There's just no space.
Manager: Anything you can do to fix it?
Techie: I can throw together something with NAT in a few weeks, that'll let us keep going, but really we need to move to IPv6. It's going to cost millions to fix.
Manager: But... this NAT thing... that'll fix it? And it's cheap?
Techie: Well, yes, but -
Manager: And it'll let us keep getting new customers?
Te

"Damn you filthy file-sharers! Thanks to you, at my last party I only had seven buckets of blow and forty hookers rather than the ten buckets and sixty hookers that are accepted as an industry-norm for this type of affair. Damn you all!"

Those aren't insurmountable. We're talking about a transition period here, so the assumption is that people will have unNATed IPv6 addresses, and you can use those to connect to peers. VoIP also doesn't necessarily need to allow incoming traffic, as long as there's a central server that can bounce the traffic. Services like Skype and MSN already do this, because customers usually aren't handy with opening ports.

Many ISPs hate P2P software because it uses so much bandwidth they are forced to spend more on their infrastructure, and some also hate VoIP because it competes with their very lucrative phone businesses. I imagine that if they were to incidentially break both while deploying NAT, they would be quite happy with this. Plus many of those ISPs are also cable TV companies, or otherwise have business ties to media production, which gives them another reason to celebrate their 'accidential' breaking of P2P.

Let's not turn this into another NAT vs IPv6 debate...The only problem between large scale NAT and ip-reputation-based ip systems is that the mappings are too transient and too broad to be useful for reputation, also they are talking about sharing ips between subscribers, right now, that's more rarely done and not to that scale(socks4/5 let people share addresses with a process on the natting machine to act as a nat-helper, so it's not a new problem). And that suggests the fix the fix has always been to mo

IPv4 IPs will become a scarce resource and as such will get reallocated from less lucrative customers to more lucrative ones. Whether that allocation will only happen within ISPs or whether it will be allowed to happen between ISPs is unclear at the moment but it is pretty sure to happen.

Those who aren't profitable enough to give a public V4 IP will still need to reach IPV4 only servers and/or use IPV4 only applications (remember apps both client

Afaict windows didn't have getaddrinfo until XP (unless you count the version in the IPV6 technology preview for 2K). It's predecessor gethostbyname only supports IPV4. MS does offer a wrapper to help with this but afaict that only helps if you are coding with MSVC[++] (I ended up writing my own wrappers for fpc/delphi, not too hard but definitely extra effort)

Further it seems while windows has wsaasyncgethostbyname there is no wsaasyncgetaddrinfo. So if you want to do a v6 capable name lookup without blocking the rest of your app you have to do it on another thread.

P.S. yes I HAVE implemented code (in delphi style pascal) directly on the low level apis that supported both v4 and v6 and async lookups (by using a thread) and supported older operating systems (by using getprocaddress and my own "v4onlygetaddrinfo" if the getprocaddress fails). I wouldn't exactly call it trivial though.

The protocol agnostic socket functions (getaddrinfo() and friends) were not part of POSIX until 2004, and were not widely supported until a bit later (even now, most resolvers don't check SRV records when using getaddrinfo()). If you've got any C libraries that are more than a couple of years old, they'll either only support IPv4 or need different code paths for different network protocols (and guess how well tested the IPv6 path will be).

They gave me a/29 + a/32 for my router for home use and probably would have given me more if I'd asked. At work I asked for a/28 and got a/27.

They also give out a/48 IPv6 subnet to all customers and instructions for use. They can do IPv6 over PPPoA (this is the UKoGB) natively and provide a IPv6 to 4 tunnel broker for those that need it.

Have a look at your Spam Assassin headers and see that quite a lot of marks are not related to IP address. I have found DNSBLs handy up to now but I think I'll accept that as these lose their efficiency during IP version handover my spamds and MTAs will get a bit more of a battering for a while.

Never mind processing power is pretty cheap.

I have a customer with around 16 million unique IPs trying to get in each week - a spambot net of some sort (Russian and Chinese IP feature a lot). An Exim process is being spawned for each connection along with a spamd and possibly clamd session. The box is a dinky Dell single processor server and it barely breaks a sweat.

My ISP (AAISP) actively encourage IPv4 address exhaustion AFAICT.It's really not in ISPs interests to conserve IPs at this point. The more IPs they can get out of the RIRs now the more IPs they will have to reuse for more lucrative customers later.

No one is going to put mail servers or any other kind of server on an LSN IP address if they can help it. With the gradual re-allocation of 'consumer' IPv4 address blocks to LSN, there will be enough static IPv4 addresses for public facing servers for decades to come. Not pretty, but that's the way it is.

And if there were a shortage of static IPv4 addresses for servers and others willing to pay extra for them, there are no end of much mor