Slashdot Mirror
IPv4 Address Use In 2008
An anonymous reader writes "The world used 197 million new IPv4 addresses in 2008, leaving 926 million addresses still available. The US remains the biggest user of new addresses, but China is catching up quickly. Quoting Ars Technica: 'A possible explanation could be that the big player(s) in some countries are executing a "run on the bank" and trying to get IPv4 addresses while the getting is good, while those in other countries are working on more NAT (Network Address Translation) and other address conservation techniques in anticipation of the depletion of the IPv4 address reserves a few years from now. In both cases, adding some IPv6 to the mix would be helpful. Even though last year the number of IPv6 addresses given out increased by almost a factor eight over 2007, the total amount of IPv6 address space in use is just 0.027 percent.'"
great, so now we're at 8 IPv6 sites, all of which are tunnel brokers!
the total amount of IPv6 address space in use is just 0.027 percent
So how many is that, in quadrillions?
The ISPs don't care if the IPv4 addresses run out. They like it because then they'll be able to start charging extra for IPv4 and IPv6 addresses whereas they've been just giving them out for free. NAT also cuts their traffic costs because it keeps customers from running servers.
Instead of waiting for demand to outstrip supply, the IANA should artificially increase demand by bloating the prices for blocks. This will cause everyone to focus more on IP conservation. Because let's be truthful: IPv6 isn't going to be widely adopted in 5 years unless something changes (and it's best for everyone if that "something" isn't a complete lack of IP Addresses)
What's to prevent someone from buying them all and charging more later?
An open market for IPv4 addresses would solve the 'depletion' problem by encouraging the most wasteful users to sell their addresses.
Get your IPv6 addresses here: Tunnelbroker.net
They've got a ton of presences all over the place, so latency is not too bad. It's really nice to be able to SSH directly to your boxes behind your router. Every address you get contains the square of the IPv4 address space for your own use.
Then bug your ISP to give you native connectivity.
Ninnle Linux broke the IP barrier a couple of years ago, and has implemented something that will soon render the whole notion of IP addresses completely obsolete.
What is .027% of 2**128
Here's a neat (and understandable) place to find out just how stupid it is to say that "only X%" if IPv6 is assigned: http://www.tcpipguide.com/free/t_IPv6AddressSizeandAddressSpace-2.htm
IPv6 is HUGE. I didn't even understand how huge until I found out I can get an address for every friggin cell in my body.
Weeeee!
I don't know which ISP's or upstream providers you are dealing with, but in the last 2 years, every DS1/3 circuit I have ordered required quite a bit of justification for anything more than 5 IPv4 addresses. No, I have not had to pay extra for addresses yet, but I have been told by AT&T and others that /24 blocks are basically impossible to get on anything less than DS3's nowadays.
The last time I did get a /24 or larger block of IPv4 addresses was 3 years ago on a 6mbit bundle of T1's. That was a /23 for a hospital network of 5000+ internal hosts. At last check, we were using about 200 of our allotted 500+ addresses. A bit wasteful.
I remember getting T1's in the mid-to-late 90's, and there were no questions asked- you just got a /24.
Never trust anyone who takes pride in being called a 'geek'....
I don't understand why they made IPv6 the way they did.
Sure, the size of the new address space is absolutely staggering, but this was done at the expense of making them impossible for a person to remember. Right now, I can go to some internet cafe and ssh into my home network because I can remember the IP.
Were I using an IPv6 address, I would have to pay for DNS service just so I could log into my own network remotely, or keep a scrap of paper and laboriously type it out.
Why not extend IPv4 by adding more bits to the representation of each octet? For example, instead of using 8 bits, use x bits where x is specified at the beginning of the address. For example, you can use x=10 and create an address up to 1024.1024.1024.1024.
This still allows people to remember them easily, as there is no difference between remembering, say, 189 and 857 from a human brain perspective. It's three digits in each case. And, you can go as high as you need to. You can never deplete it, as you can just keep using more bits to represent the address when necessary, and all of the applications supporting such a protocol would be able to support that natively.
Best of all, assume x=8 unless explicitly specified, and voila -- perfect backwards compatibility with the existing IPv4 protocol. You no longer need to have separate treatment of IPv4 and next-gen address spaces, because IPv4 will be a subset of the expanded space.
Why the current mess of horrible alphanumeric sequences? Why didn't they make it easy on our eyes and do it like this?
Even though last year the number of IPv6 addresses given out increased by almost a factor eight over 2007, the total amount of IPv6 address space in use is just 0.027 percent.'"
IPv6 addresses are 128 bits instead of v4's 32-bits. I sure HOPE the percentage stays small.
It's a preposterous claim that a whole 0.027 IPv6 addresses are in use. If that many addresses were in use, then that would mean IPv6 is wildly successful
If you just consider the first 48 bits of a V6 address. That's 281474976710656 network addresses.
IF 0.027% of those are in use, then 75,998,243,711 IPv6 networks have been used, which is more networks than IPv4 has ip addresses.
The full 128 bits allows for 340282366920938463463374607431768211456 host addresses.
If 0.027 of those are in use, then that would mean 91876239068653385135111144006577417 IPv6 host addresses are in use.
A lot of IPV4 addresses are owned by ISPs hosting spammers. If we can reclaim those, i think we can live a little longer with IPV4.
There's a whole ton of IPv4 address space that seems to be allocated to people that don't realistically need it. For example, HP, Apples. IBM, MIT, Ford, Digital, Halliburton, GE, Xerox and a bunch more all have /8's. AT&T has two /8's. Do these companies really need 16 million public IP addresses?
I know of many universities that have /16's, and really, same situation - do they really need 65k addresses? Labs, residence PCs, wifi laptops, are all assigned public IPs, and then behind a firewall so nothing is accepted inbound anyways. These systems could easily be assigned private addresses and stuck behind NAT.
Why don't we just tell them they have to justify use of all their IPs, and then in a year or two, subnet the crap out of their space and take over anything they're not using to serve internet-facing services? It would likely free up a few hundred million IPs, extending IPv4 space for a few more years.
Speak before you think
Sounds like a lot (maybe half?) of allocated addresses are not in use. I wonder how the cost of turning /23s into /24s compares with going IPV6 everywhere?
http://michaelsmith.id.au
Because IPv6 was an awful mistake, an abortion created by a project group (IPNG) that had become so politicized that the best people had left. The remaining participants were hardly even the B team; they were F Troop. IPv6 was a mashup of two undergrad-level hacks, Steve's IP and Paul's IP, by Steve Deering and Paul Francis. Steve has disclaimed IPv6 and Paul's in a daze. All this was done before "ISP" was a household word -- it was still the NSF's private network.
So IPv6 perpetuates IPv4's mistakes and adds more of its own. It is costly but doesn't fix anything.
The existing v4 space is not well utilized. Blocks can be traded/bought/sold in the interim until something smarter than IPv6 comes along. IPv6 at this point is mainly a hack by equipment vendors to make you buy costly new stuff.
NAT is harmless to any application that is not broken in the first place. There is never justification for putting an IP address inside the application layer. Look at HTTP: It uses names, not addresses. In fact, it was a mistake to have applications resolve DNS; that should be a function of TCP/IP itself.
Doesn't this just prove the point? Do you really want 5000+ internal hosts on a hospital network to be directly accessible from the Internet?
It seems in your case you should only require routeable addresses for your external servers, firewall, vpn, etc. and let everything else live on the inside.
So if you're ordering up all of these circuits please do us all a favor and don't even ask for more addresses than you actually need. Thank you very much.
load "linux",8,1
Now you can still get n times 2^80 IP-Addresses for free from tunnel brokers like Sixxs.net. They even offer reverse DNS delegation and such things. You won't get that level of service from your local ISP, ever.
NAT is fine for a typical workstation now but I think it is a bad idea to build assumptions about the way applications work into network architecture.
http://michaelsmith.id.au
While China and the US consume the world's resources, even the virtual ones the rest of the world is trying to adopt more efficient methods? Same old familiar story.
Analytic & algebraic topology of locally Euclidean meterization of infinitely differentiable Riemmanian manifold
You apparently don't run any servers either. Just because someone uses NAT does not mean they cannot run a server. If you have a web server in your home and your ISP assigns you a public IP address, your modem (DSL) or modem and router (Most Cable) simply utilizes PORT FORWARDING. If its a standard web server, you simply direct port 80 to the internal NAT address of your server (ie 192.168.0.100, or 10.0.0.10, or whatever...)and voila. FTP? Use 20/21. Not too complicated.
Try running more than one HTTPS server behind a single external address and see how wonderful you think NAT is then.
Why not just take every existing IPv4 address and make it an alias for the same IPv6 address, but with 5 zeros in front of it? And declare that the owners of those IPv4 addresses now own the corresponding IPv6 addresses?
Technoli
Why would you use addressing to keep un-authorized traffic from your computers. That is what a firewall is for. The whole NAT thing is really frustrating if you are trying to do any push application, VPN, video-conferencing...etc. Yes there are ways to cope, but why port forward when you could open ports in a firewall?
I had no idea exactly how big either. From your link:
[...]imagine the IPv4 address space is the 1.6-inch square above. In that case, the IPv6 address space would be represented by a square the size of the solar system.
It's perfectly fine to make assumptions, in fact it's part of designing stuff. You can't know everything in advance.
;) ) the designer was.
;) ).
You WILL have to make assumptions anyway - after all you aren't going to ask for 2 billion IP addresses for the hospital. Even if someone argues that in the future some applications may require machines to have thousands of IP addresses, but as a designer you are going to say "Even if that's the case, a hospital is unlikely to want that app, or by that time, the hospital and the world would have gone to IPv6".
How good the assumptions are, shows you how good (or lucky
It's perfectly reasonable to assume that most computers in the hospital should never need to have outsiders able to connect directly to them.
This may not be true for universities, but it is likely to be even more true for banks - only a very few ways in and out.
Many universities have an open campus, and outsiders can walk to any building and try to enter them, and the buildings themselves are designed with multiple entry points. Banks in contrast are desigend to have just a few entry points (that's why the crooks often make their own entry points
No, 5000+ hosts do not need to be *directly* accessible from the internet, but there are an exponentially growing number of devices and information stores that need to be accessed by vendors and business partners (a good example is the change to digital diagnostic imaging by many hospitals over the last few years- those images have to move from hospital to hospital and hospital to clinic somehow). While solutions like Citrix or SSL VPNs are solving many of these issues, often direct VPN access is the only solution. With the VPNs, classic LAN-to-LAN tunnels within NAT space (RFC 1918) are not only prone to conflicts, but are complex to secure. Landing VPNs on routeable addresses outside the firewall (then pin-holing) is most often the only logical choice.
In the specific hospital case above (and this problem exists in many more industries besides healthcare, I'm sure, but healthcare technology is my area of experience)- based on the growth of connected devices, I will be out of IPv4 addresses in about 2 years. Maybe I was a bit loose with my 'wasteful' comment above- but in hindsight I am glad I hoarded when I did. Those remaining 300 routeable addresses are becoming precious. The days of handing out large IPv4 blocks are over as far as ISP's see it, so do I start hoarding more IPv4 addresses now? Sadly, I will probably have to, even if I am charged a nominal fee; it will most likely be cheaper than implementing IPv6, at least in today's skill-set market.
Never trust anyone who takes pride in being called a 'geek'....
I'm moving an installation from telco-owned to a carrier neutral facility (Equinix). I was able to get a /20 without a problem (although justification was necessary). Justification is ALWAYS necessary with ARIN, as they're strict with the IP space (as they should be).
When will consumer grade routers support IPv6?
When I can go and get a netgear, linksys, or dlink router that supports IPv6 then I'd hope that I can get IPv6 connectivity from my ISP. (QWest)
I'm running Vista and Linux here at home, and could operate on ipV6 without any issues right now, except that I guess most software is only configured to talk ipv4. (Does Firefox attempt to talk to any ipV6 locations?)
No thanks. Not even if they swear on a stack of bibles they'll never sue.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
ipv6 = 128 bits.
mac address = 48 bits.
does that mean that mac addresses will be duplicated?
garanted, not soon, since 2^48 = 281.474.976.710.656, but i don't understand... does this mean that mac will lose a lot of their current uses?
i mean, if you rewrite mac specs, you have to revrite ipvX specs, so you got to reuse mac addresses...
what percentage is going to be wasted?
And why is it a good idea to make routing tables simple? IPv4 routing tables must be hideous if were running out of IPv4 addresses.
Which is fine - after all, there should be plenty of addresses, right? So why is there nowhere that will give me, as a private individual, an IPv6 address (officially, I mean - I'm aware of that website that generates an address that should be ok to use)?
This sort of thing should be what drives the IPv6 transition - I'm willing to experiment, to find problems and fix them. But the system is such that I am locked out of doing so.
I am trolling
When I was in France, my ISP gave me IPv6 connectivity at home for free. Not all ISP in France give IPv6 but that's a start. When I moved to UK, I only have IPv4 and I think most ISP here give only IPv4. Do we have some statistics per country? What are the countries more advanced in IPv6 for the end-user at home?
Or, more obvious for a home user... two copies of any online game on two machines in the house.
Port forwarding is an ugly hack designed to work around an ugly hack. You should be using an IP per machine even now.. it's not like they're hard to get, I got 16 just by asking nicely.
Ipv6 6to4 config generator for Debian and Ubuntu. No registration needed, just an IPv4 address.
they might actually create a distro with that name. You have provided searchability for it for 6 years. Of course, they would then have to be everything that you have claimed. Still, it might be fun.
IPv6 is the way to go.Able to control a great deal more. Back in the 80's and 90's, nearly all of the IPs were public spaced. I want that back.
I prefer the "u" in honour as it seems to be missing these days.
So DNS is your friend. It works well, fast, and reliably.
Unless your name is Kaminsky,
Both will be very expensive, and why would any company in thier right mind want to give up scare addresses (and right now they can't legally sell them though that may change)
I suspect that when IPV4 addresses do finally run out ISPs will force residential users behind nat and re-use their addresses for more lucrative customers.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
The current situation with most residential ISPs is that each customer gets one public IP. This is typically terminated on a NAT router (either combined with the modem or as a seperate device). In this situation you can port forward because YOU CONTROL THE NAT.
When (not if) IPV4 addresses run out I strongly suspect the first thing the ISPs will do is force residential customers to either pay more or go behind an ISP LEVEL NAT (in some countries afaict they are already doing so). By doing this they will free up adresses for more lucrative customers. Since this nat is shared between multiple customers the customers will almost certainly not control the nat and will therefore not be able to set up port forwards.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
They mean out of all addresses in use, only 0.027% are IPv6.
global recession will slow the demand and use of ip4 space, so ip6 adoption can be pushed out 5 to 10 years more, just like it's always been for the last 20 years.
NAT also cuts their traffic costs because it keeps customers from running servers.
Aside from TOS issues, running servers (at least web servers) is no big deal. I've run a web server for years on dynamic IP addresses, thanks to dyndns.org.
For all practical purposes the IPv4 address space has already run out. Just look around you, your friends and colleagues are all behind some kind of NAT proxy. For a consumer it is in most areas not reasonably possible to get a fixed IPv4 address. And this has brought us all the NAT problems, hacks and horribleness. And even with all that trickery, or probably more realistically because of all that trickery, lots of things that should work don't, or don't work all the time, behaving erratically. This is not the Internet I thought we were going to get, back when I was still dreaming in the nineties.
I don't think it's even fine for a typical workstation now.
I have to jump through so many hoops and deal with so much hassle to get through NAT issues with certain programs... maybe you'd say a typical workstation would just give up, but from where I'm standing NAT gets in the way of even some common workstation programs from voice/video over IP to cluster computing.
While it may be enabled by default in some OS's, most of them lack the required DHCPv6 support. While stateless autoconfiguration works, you won't get DNS server addresses from the router directly, which kinda sucks as v6 addresses are challenging to remember...
Mac OS X doesn't yet support DHCPv6 so I have to manually configure my nameservers.
What do you mean, 'I' have provided searchability for it for six years? I'm hardly the only Ninnle user on the planet. I just do what anyone else here does, and that is to recommend something that I use, find effective and believe it. Besides, I've only been tuning into /. since 2005.
I just received a /24 for a small network from AT&T on a link quite a bit smaller than DS3. I also received a /24 from another ISP for this same network on a slow link.
Apparently needing BGP still gets you past the gatekeepers. Sure, you can do BGP with smaller subnets but it requires some careful consideration and planning and you lose a lot of your control. The ISP's fortunately understand this and will still hand out /24's.
You are confusing "Publicly Routable" with "Directly Accessible" This is a distinction which cheap consumer-grade "routers" have blurred and it's even starting to seep up into the minds of network engineers.
You can have devices using NAT to RFC-1918 address that are just as "directly accessible" as any other host. Likewise you can have machines with routable addresses that are not in any way connected to the Internet. There are lots of valid reasons to do both depending on the applications, the hardware and the infrastructure.
The problem lies in any apps written since the mid-1990s that make two critical assumptions about its own network layer (IP *or* IPv6) address (NLA, generically), and the same about its counterparties'.
Assumption one: the local address is universal and isotropic.
Assumption two: the local address is fixed and permanent.
These assumptions are bad with or without the presence of NAT, because of DHCP, renumbering, multihoming and mobility.
The first assumption leads to the embedding and use of NLAs in higher level protocols that lead to breakage when the NLA cannot be used as a destination address as it is. This can be because of transient routing problems (or deliberate policy), and can be avoided simply by using a simple indirection through the DNS or equivalent mapping database that will give up one or more NLAs which are valid as destination addresses.
NAT mainly serves to increase the incidence of problems associated with assumption one, because it generally introduces anisotropy to addresses. Obviously if "A" knows it's 10.0.0.6 and tells a counterparty "B" to connect to it at that address, if B is somewhere far away topologically, "B" is unlikely to be able to make use of it. One solution: embed symbolic DNS names into the stream and indirect through that. Instead of "10.0.0.6" with the assumption that a well known port (e.g. TCP, 20) embed (for example) ftp-data._tcp.mysymbolichostname.mygatewaydnszone.somesite.com into the stream and expect the other side to use do a SRV RR lookup in the DNS.
A bit of glue to tie NAT-and-firewall-hole-punching into an on-NAT/on-firewall nameserver is most of what's necessary to remove the need for application-level gatewaying and translating for simple connectivity purposes.
Older protocols (like ftp) are going to remain a problem; the reasons these have not been fixed already are largely political -- these older protocols are known to have serious security problems, and there are many people who reject wholesale the idea of adapting to the existence of NLA anisotropy in the real Internet.
This also gets in the way of host and subnet mobility and multihoming. We lack a standard session protocol which would allow for generic graceful reconnects of application-to-application communications as e.g. a mobile phone moves from a wifi to a 3g wireless provider and then to another wifi unrelated to the first; or as a conference attendee walks with her laptop from the conference wireless network to her hotel room. The standard again would largely involve a bit of glue around DHCP and dynamic DNS, and is stalled for mostly political reasons (security of DNS, and acceptance of this mode of mobility necessarily leading to transience of addresses and typically leading to transitioning from one anisotropic address to another).
NATs are simply there. Not adapting to them for aesthetic reasons is a poor engineering choice. Complaining that they are in the way is complaining about that engineering choice.
Port forwarding through a stateful firewall and NAT hole punching are identical for a higher level communication that does not embed network layer addresses (NLA, in this case IPv4) and expect them to be useful for the other party or for a long period of time or both.
Think of a trivial service like echo (TCP, RFC 862) where whatever application data is sent from the client is reflected back to the client unchanged by the server. If the client connects to 128.100.100.1 tcp port 7 it does not matter whether 128.100.100.1 is the actual server address behind a firewall that allows that connection, or is the address of a NAT that forwards port 7 to an internal host. Right?
Complex services which require rendezvous often have made unreliable assumptions about NLA lifetime and isotropy. These assumptions are the source of frustration. The lack of a stanard generic workaround for future rendezvous in the presence of ephemeral NLAs is another problem.
Trying to make NLAs non-ephemeral is a poor solution (it ends up becoming bridging); a better one is to have a stable handle that maps to a dynamically updated NLA/service-address. Wide Area Bonjour does this (mDNS + dns-sd + private dynamic DNS zones for updating A RRs and SRV RRs as they become discovered through NAT-PMP, uPNP, probing and feedback), and it helps with any application protocol that transfers DNS names and symbolic port names as rendezvous points instead of IP addresses (with implicit mappings for well-known ports).
Essentially all Mobile Me (formerly .Mac) users have a private (key-protected) DNS zone membername.members.mac.com that is updated by their various Mac OS X systems so that they can rendezvous with one another ("Back to my Mac"); the zones mainly contain A and SRV RRs keyed to the configured Computer Name (in System Preferences > Sharing).
Most Mobile Me customers can therefore do things like:
ssh mycomputername.mymembername.members.mac.com
which will result in a DNS service discovery query of
_ssh._tcp.mycomputername.mymembername.members.mac.com
which will resolve a SRV RR like
0 0 22 computername.real.dom.ain.
(and/or possibly other RRs like PTR, A, AAAA, CNAME or TXT).
Behind a NAT that might become "0 0 2193 nat-dns-name.some.where." or "0 0 41111 128.100.100.1".
ssh then will resolve the DNS name or use the IP/IPv6 literal, and use the port literal, and connect appropriately and seamlessly; host key checking is done on its argument, rather than on the intermediate indirection symbolic names or the ultimate NLA.
This works just as well for datagram type services as for connection-oriented ones.
Most of this is unencumbered open standards documented at http://www.dns-sd.org/ (for example).
The point however is to use something that really is long-lasting and isotropic, like a DNS name, as a rendezvous point. The Back to my Mac approach is illustrative, but is not a good choice, since key-protected private DNS names obviously are only isotropic for those that know the key!
A standard API for this sort of rendezvous among hosts that are subjected to NATs and being moved from one part of the network to another, and a general consensus about avoiding the use of NLAs as remotely-useful long-lived rendezvous handles, has been elusive in the IETF, mainly for political reasons.
This is particularly sad since many IETF conference goers migrate their own laptops from the conference wifi to their hotel rooms several times during the conference, and many of them have home and work machines behind a NAT or firewall they do not personally control, and yet they don't seem to mind the lack of session survival (or the hotchpotch of per-application recovery approaches) that results.
You've overemphasized small problems here and underemphasized large ones.
"A bit of glue to tie NAT-and-firewall-hole-punching"? Really? It's just that easy?
What about the serious problems with NAT hole punching, it's unreliability and complexity due to details of the particular NAT implementation? What about the policy issues of firewall hole punching? These aren't trivial problems to overcome; we've been trying to get various hole punching techniques to work for years and it's still crappy, unreliable, and un-userfriendly.
NATs don't suck for aesthetic reasons; they suck because they get in the way of operation and have to be worked around through the use of voodoo and luck.
Yes. http://www.dns-sd.org/ for DNS queries with dyanmically updated A and SRV RRs (among others); NAT-PMP or uPNP or STUN (or Teredo) for acquiring the information to update into those RRs.
Literally millions of people use these technologies daily as part of either using Back to my Mac, using a Mac OS X system behind an Apple Airport wireless station, or both. It works pretty well, and users don't even notice other than seeing their various machines in Finder window sidebars as they move their laptops around from subnet to subnet. It's also straightforward to put a NetBSD system into the mix (probably other similar sytems too), or to set up your own multiplatform Wide Area Bonjour server.
Gateway implementation bugs are not necessarily NAT-specific, as you note. Any feature -- new or existing, optional or mandatory -- can have bugs.
Policy issues affect non-translating firewalls just as they affect translating firewalls.
No, they aren't trivial problems (bugs bad; policy elucidation or creation problems bad) but they are not specific to NAT.
That NATs get in the way of operation should be incentive for generic workaround API development, rather than hoping that the NATs will just get out of the way. They're established and aren't going to vanish soon.
Listen to yourself: "generic workaround API development"? Really? The simple keyword "workaround" is a pretty striking clue that these engineering issues aren't aesthetic.
As for hole punching, I hear often that it's very successful, reliable, even easy to do. And yet in my personal life I'm struck by instance after instance of myself, my friends, family, and coworkers hitting up against non-working software where the problem can be tracked back to failed hole-punching.
It's one of those "Who are you going to believe, me or your own eyes?" things: everyone says holepunching works, but I see first hand from a wide variety of programs, in a wide variety of environments, operated by a variety of independent users, that it fails 90% of the time.
Then, I try to look research the issue in software I run myself only to find developers insisting that there is no bug while I myself can't find them either.
So who am I to believe? My own experience, based on far more than a few isolated occasions, shows pretty conclusively that hole punching doesn't work reliably.
They're there. You have to work around them. That's an engineering fact, not a comment on their aesthetics. Such aesthetic concerns are not really in the realm of engineering; it is not engineering if you are unwilling to engineer a fix or workaround just because the problem is ugly.
Moreover, simply repeating "NATs are ugly" or listing off justifications for that opinion is not going to get rid of them.
That there are difficulties in NAT traversal for protocols that require knowledge of counterparty NLAs or for applications that require rendezvous with particular counterparties at arbitrary times is a truism, not an argument against engineering a generic workaround API.
Confusing a truism that is part of the problem statement with a solution is poor engineering practice. "If only they weren't there!" does not make NAT traversal easier for anyone.
That said, there are several largely working toolsets for doing NAT traversal; several are open source, freely available and probably unencumbered. The people working on them accept bug reports, especially where your (reduceable, repeatable) experience conflicts with the expectation of "it just works". Presumably people working on 3rd party applications that have problems traversing NATs take bug reports too. You know the drill.