They're not late to the party. The WRT-54GL is a wireless G router that doesn't support 802.11n
And Netgear's new offering might be the only game in town that can run DD-WRT AND support 802.11n (?)
The difference between 54 megabits and 600 megabits is extraordinary, especially when wanting to stream HD or video content across your LAN, play some games, move ISOs around, etc.
It's true, but the registries, and ARIN particular has not handed out/8s liberally, not in the past 10 years they haven't.
The policy is to provide an ISP up to a year's supply of IP addresses maximum (after they've been an ARIN member for long enough), based on their network design, and justified need.
Unless the ISPs committed blatant fraud and massive overexageration on their IP applications, they don't have more than a year's supply of unutilized/24s laying around.
Maybe they indeed have..
This is no consolation to the ISPs who have followed the rules...
Or providers with multiple upstreams... as you can't just take an assigned unutilized/24 from your upstream's PA space and expect to reliably multi-home with it (even when your link to the primary provider that issued the IP block goes down), due to aforementioned filtering.
In North America, at least, an organization applying to receive IP addresses has to sign a contract with the registry (ARIN), before any IP addresses will be assigned. Some of the terms of this agreement are designed to prevent "selling" or "sublet'ing" ip space.
Also, guess what... if the registrant of record fails to pay the bill, ARIN permanently revokes the IP address resources after a certain period of time. This is like leasing a property for 99 years from someone who doesn't own the property.
Some of the provisions of the contract include:
9. NO PROPERTY RIGHTS
Applicant acknowledges and agrees that the number resources are not property (real,
personal, or intellectual) and that Applicant does not acquire any property rights in or to
any number resources by virtue of this Agreement or otherwise. Applicant further agrees
that it will not attempt, directly or indirectly, to obtain or assert any trademark, service
mark, copyright, or any other form of property rights in any number resources in the
United States or any other country.
(i) Except as provided in 15(a)(ii), Applicant may not assign or delegate this
Agreement or any of its rights or obligations under it, including without limitation the
exclusive right to use the number resources allocated or assigned to it, without
ARINâ(TM)s express written permission,
(ii) The event of any transaction (whether a merger, acquisition, or sale) in which
Applicantâ(TM)s controlling managerial and/or voting interest changes during the term of
this Agreement shall be considered an assignment, so long as the Applicant provides
ARIN with written notification within thirty (30) days of such assignment.
(iii) Any attempt by Applicant to assign this Agreement or any rights or obligations
under it, other than as provided in this Section 15(a), will be of no force or effect.
In the IPv4 world NAT is very common, and NAT keeps just as much state information as this would have to.
This is something that would be implemented on edge devices primarily. It can be implemented on the edge, there's no reason for this gateway scheme to be implemented on the core.
The ephemeral IPv4 addresses created can also be specific to the client just like NAT translations are.
But in case you haven't noticed: memory is cheap now, and stateful designs such as NAT setups are now being used even in high-rate systems, and carrier grade NAT definitely requires storing a lot of state info.
The password or secret key is just an obscure token that your adversaries aren't supposed to know. All internet systems in the world that allow remote access (except unprotected ones) are protected by obscurity.
Security through obscurity is only bad when you are referring to the security of a communications protocol or security algorithm (such as a cipher, message digest, or encryption method).
When it comes to security of computer systems: obscurity is always the main thing guarding the gate.
Being under 100% utilization is small comfort for the new organization that wants to get some internet connectivity, or the organization that's opening an additional facility and needs full internet connectivity for their new web farm...
The few currently unused IPs in Customer A's/24 are quite unavailable to Customer B.
Not all/8s are used for client networks that you'd see web browsers from.
The 1.0.0.0/8 was been widely used by many organizations as their own "private internal address range" (before RFC1918), and still the case, that IANA would be unlikely to ever allocate this.
Nowadays 1.0.0.0/8 is used also for anoNet, and 5.0.0.0/8 for zero-configuration of certain internet apps.
It's not like the addresses can be allocated without major caveats.
14.0.0.0/8 is allocated to to the international system of public Data Networks (X. 25 gateways), these IPs map to their X.121 addresses, as indicated by rfc 1356, see RFC1700, page 181.
When you say auth only... it's not "when hell freezes over" it's once in a blue moon.
All they gotta do is get a reliable crack for RSA/DSA, probably by building a quantum computer and successfully implementing Shor's algorithm on a large scale:)
Don't set 'PasswordAuthentication no' * out the password for the SSH-only allowed users. Or even better yet, run ssh on a non-standard port, and do a fake SSHD that always denies and connection tarpitting on port 22.
That way the 'brute forcers' will have no idea your system is more secure. While they're wasting time trying to break security on your uber locked down systems, they're leaving some other systems alone. If they're trying to brute force X hosts at a time, and some of them are secure, it will be longer before they move along to possibly more insecure hosts.
This reduces the rate of expansion of these annoying brute forcers
I lost a bunch of books that were precious to me in the Katherine flood in 1998
Ok, yes.. nothing is going to be completely secure. An eBook might (if it's not DRM'ed, and you have offsite backup).
I'm thinking more along the lines of: when I buy a physical book, Amazon can't delete it from my bookshelf, without me knowing.. the book won't just vanish. If I have a kindle, that's a very real possibility
I regularly have more than one book 'on the go' for entertainment purposes. Something serious for when I'm ready and willing to engage in a serious text that demands concentration
Perhaps.. but are you going to read your entire book library on the go? Most people will take one or two books on the go, unless it's something rare like a long trip..
Yeaaaaahh.. Ok, that really is the killer. I've lost more books to friends than to the above flood. Including first editions. Yeah, I'm talking to *you*, Gary, you thieving fucker. Bring it back and all is forgiven. 'Loaning' a pdf or other digital format is a gift, not a loan, and you don't have to keep track of your flaky friends and their propensities to forget where they got books from.
The main problem is the publishers' DRM formats lock the book to the reader, so you either can't get the file off your reader, or when you transfer the file to your friends, they can't read, because their reader isn't "authorized".
Of course if you have plain old PDFs, matters are different...
The run out date for the RIR IP address pools has not been continuously changing to 'about to run out'. It changed exactly once, due to the adoption of a new technology and an entirely new addressing scheme (CIDR).
The 2011 run-out date was forecast by the folks who compiled the IPv4 address report work back in 2005, and the expected year of run-out has not changed. In fact, so far the model and the predictions have shown to be fairly accurate.
There has not been inconsistency or divergence between the reports and reality.
The reports are certainly more compelling than an anecdotal claim that "We've been 'about to run out' of IPV4 addresses for over 10 years."
In this case, freely allowing the purchase and sale of parts of IP blocks piecemeal would be an internet routing table disaster.
The routing table has already gone over 300,000 entries. Filtering is already a reality for many sites, and many ISPs, common equipment already can't handle the full routing table much longer at the current rate of expansion.
Equipment that can do better in hw is extremely expensive, and out of reach of much of the market.
Now, the registries today allocate blocks of IP addresses in a manner that allows filtering.
For example, if you get a/22 for multi-homing, that block gets allocated from a block from which only/22's are allocated. That way, everyone can filter to the/22, you advertise one/22 route, if you try to break up that/22 and advertise 4/24 routes, for traffic engineering, you can do it, but many sites will filter it.
The same applies to organizations who get a/20 direct assignment, they can chop up their/20 into 16/24s and also advertise each one with different values or from different places for traffic engineering, and it's common to chop that up a bit, but most sites will filter those, and only their/20 announcement is propagated.
Now, imagine if policies were different, and you got a/19 you later didn't need half it. You are supposed to return the/20 you don't need to the registry and exchange keep only the smaller block if this happens.
But imagine you didn't... you sold 16/24s (256 IPs each) to 16 different entities.
Now they each want to announce them (they're not connected to you)... that's 16 more entries in the routing table.
Ok, that matters but is not massive.
What is HUGE is the fact that when people apply their filtering rules (accepting only/20 or larger) advertisements from your block allocated from a block from which only/20s are allocated.....
Suddenly those networks you 'sold' those blocks to
aren't reachable by networks in the DFZ that do this filtering.
And they'll be complaining to them, demanding they relax their filtering, which ultimately causes costs to be massively increased for everyone, or their equipment blows up, or they tell the people you sold IPs to to go get a proper block... in any case, the result is bad for the community
Even though you benefit from selling IPs, and they benefit from being able to get them from you, the community as a whole incurs a massive expense, it's basically an abuse of the commons.
Yes, there was a serious IP shortage looming 10 years ago. The issue was a boneheaded allocation strategy that provided most users more IPs than they needed. Everything was either a number of/24s, a/16, or a/8.
The introduction of CIDR bought some time, because it made allocation as efficient as it can be in IPv4.
The EU Commission's report was not credible.
The IPv4 Address Report is.
This is not the sky falling, this is the big fat meteor inching down bit by bit. It finally hits, and causes epic cataclysm, sometime in 2011.
It's a bit like suggesting you can sell parts of your land (real-estate) under the table, without notifying the county records office of the sale..
The problem is... there's a registered owner (or deed holder).
And having someone tell you that you can use some IP addresses is useless unless you can get traffic to them.
The action required to get traffic to go to an IP address is very public, you have to announce the IP address space using an AS number.
The only way for you to do it without setting off alarm bells is to pretend that you ARE the person you "bought" the IPs from under the table, using their AS number.
Your announcement will probably be filtered, since your IP block is a portion of theirs (it's smaller than the assignment)
So the traffic goes to them... unless they happen to be an ISP connected to you, you are now in a sticky situation.
So the difficulty in simply 'acquiring IPs' under the table, is the need to get connectivity to them. Controlling that connectivity is harder, and if the company that sold you the IPs goes bankrupt, you're screwed.
You're better off just getting your ISP to allocate you the IPs.
Either that... or buying/merging with other companies for the sole purpose of acquiring their IP addresses, and throwing away all else.
Ok... what's the band-aid solution the CEOs use when the Enterprise SQL server has less than 10GB of disk space remaining on its data drive, and business requirements demand that approximately 1GB of new data be stored every day (transaction records) ?
Are you suggesting the businesspeople won't authorize the storage system be upgraded or changed to allow more storage capacity?
There's really no inexpensive band-aid solution that effectively lets you get around IP exhaustion.
Imagine you reserve a/16 of "private address space" for name mapping.
You have a gateway that provides DNS.
When someone looks up "www.blah.com" and it has an IPv6 address, the DNS server immediately allocates an ephemeral IPv4 address, enters it into a temporary database, and returns it to the client.
Now when the client requests to open a TCP connection to the ephemeral IP address within the TTL period, the gateway will automatically receive the IPv4 packet, re-encapsulate it as an IPv6 packet with the proper destination address. Upon receiving a reply packet, it will find the matching database entry, re-encapsulate it as an IPv4 packet, and return the reply to the client.
The result is a user-transparent conversion from V4 to V6 and from V6 to V4.
The service they promise (sort of)... but they're being *******'es about it. If I understand correctly they provide article author two options (1) Use Verizon IP addresses, or (2) Use their ARIN assignment and peer with Verizon AS 701.
Where Verizon blocks announcements of prefixes longer than/32.
This is a long-standing (braindead) policy on Verizon's part, that doesn't even account for the fact that RIRs are handing out/48 PI assignments in some cases, and there can be multi-homed sites with/56s.
In other words, a third of the V6 internet. You can think of this as the IPv4 equivallent of only accepting announcement of a/19 or larger block of IP addresses.
Specifically, they are completely blocking all of ARINâ(TM)s 2620:0::/23, so even by following their policies theyâ(TM)re still providing an incomplete view of the internet. It is their position that this is âoecorrect"
âoeIf you wish your/48 to be visible globally, youâ(TM)ll need to return your direct/48 allocation to ARIN and obtain a Verizon/48 from our network pool. Since our/48 assignment would be part of a/32 that we are announcing, your network would be globally routable. Otherwise, you are limited to AS701.â
Verizon isn't well known for having complete IPv6 connectivity, a lot of "IPv6 providers" don't. If you are serious about V6 connectivity, you definitely want to get multiple providers.
In the V6 world, connectivity is sparse, and filtering is overly aggressive from the likes of Verizon and other big V4 players, almost as if they're not really all that serious about ensuring global V6 reachability. I would say 2 or 3 transit providers is needed for bare minimum connectivity. And naturally it's better if you can peer with others...
Actually, n/m, come to think of it.. many to one translations are commonly called PAT, NAPT, PNAT, or "Overload NAT".
Oh, and though it may be a matter of debate, some folks swear that it's incorrect to call those NAT.
So OLPPC (One layer of PAT per citizen) or
OLNPPC (One layer of Network and Port Address translation per citizen), OLNAPTPC, or
respectively OLNAPTC OLPNATPC, or OLNPC
IPv4 Exhaustion is expected approximately 734 days from today's date. That is just about 2 years.
It takes a lot longer than 2 years to develop a networking standard, and gain acceptance from the community, and no alternative has even been proposed.
There are two solutions on the table: IPv6 and IPv4 with carrier grade NAT.
It's going to be one of those things, in two years.
3) If you have a large enough build process, you may have modules getting compiled from different machines. Guess what happens if not all of the machines have gotten updated yet?
You never update build machines without qualifying those updates first. And once you've qualified them, you stop all build processes until update is finished, roll out the update to all machines immediately.
Re-test complete build, and if it doesn't work out, you take your backup plan and revert the update.
Slashdot Mirror
They're not late to the party. The WRT-54GL is a wireless G router that doesn't support 802.11n
And Netgear's new offering might be the only game in town that can run DD-WRT AND support 802.11n (?)
The difference between 54 megabits and 600 megabits is extraordinary, especially when wanting to stream HD or video content across your LAN, play some games, move ISOs around, etc.
It's true, but the registries, and ARIN particular has not handed out /8s liberally, not in the past 10 years they haven't.
The policy is to provide an ISP up to a year's supply of IP addresses maximum (after they've been an ARIN member for long enough), based on their network design, and justified need.
Unless the ISPs committed blatant fraud and massive overexageration on their IP applications, they don't have more than a year's supply of unutilized /24s laying around.
Maybe they indeed have.. This is no consolation to the ISPs who have followed the rules...
Or providers with multiple upstreams... as you can't just take an assigned unutilized /24 from your upstream's PA space and expect to reliably multi-home with it (even when your link to the primary provider that issued the IP block goes down), due to aforementioned filtering.
In North America, at least, an organization applying to receive IP addresses has to sign a contract with the registry (ARIN), before any IP addresses will be assigned. Some of the terms of this agreement are designed to prevent "selling" or "sublet'ing" ip space.
Also, guess what... if the registrant of record fails to pay the bill, ARIN permanently revokes the IP address resources after a certain period of time. This is like leasing a property for 99 years from someone who doesn't own the property.
Some of the provisions of the contract include:
Nonsense.
In the IPv4 world NAT is very common, and NAT keeps just as much state information as this would have to.
This is something that would be implemented on edge devices primarily. It can be implemented on the edge, there's no reason for this gateway scheme to be implemented on the core.
The ephemeral IPv4 addresses created can also be specific to the client just like NAT translations are.
But in case you haven't noticed: memory is cheap now, and stateful designs such as NAT setups are now being used even in high-rate systems, and carrier grade NAT definitely requires storing a lot of state info.
The password or secret key is just an obscure token that your adversaries aren't supposed to know. All internet systems in the world that allow remote access (except unprotected ones) are protected by obscurity.
Security through obscurity is only bad when you are referring to the security of a communications protocol or security algorithm (such as a cipher, message digest, or encryption method).
When it comes to security of computer systems: obscurity is always the main thing guarding the gate.
Being under 100% utilization is small comfort for the new organization that wants to get some internet connectivity, or the organization that's opening an additional facility and needs full internet connectivity for their new web farm...
The few currently unused IPs in Customer A's /24 are quite unavailable to Customer B.
Than the worms enabled by sloppy Windows admins who fail to apply server patches...
Not all /8s are used for client networks that you'd see web browsers from.
The 1.0.0.0/8 was been widely used by many organizations as their own "private internal address range" (before RFC1918), and still the case, that IANA would be unlikely to ever allocate this.
Nowadays 1.0.0.0/8 is used also for anoNet, and 5.0.0.0/8 for zero-configuration of certain internet apps.
It's not like the addresses can be allocated without major caveats.
14.0.0.0/8 is allocated to to the international system of public Data Networks (X. 25 gateways), these IPs map to their X.121 addresses, as indicated by rfc 1356, see RFC1700, page 181.
That's not very many IP addresses, anyways.
Let's say you're a Tier1 or a Tier2 transit provider.
There's no such thing as "segmenting that portion of your network", your customer networks are separate, period.
And you still have to filter, or fork over billions$$$ for massive upgrades...
When you say auth only... it's not "when hell freezes over" it's once in a blue moon.
All they gotta do is get a reliable crack for RSA/DSA, probably by building a quantum computer and successfully implementing Shor's algorithm on a large scale :)
Don't set 'PasswordAuthentication no' * out the password for the SSH-only allowed users. Or even better yet, run ssh on a non-standard port, and do a fake SSHD that always denies and connection tarpitting on port 22.
That way the 'brute forcers' will have no idea your system is more secure. While they're wasting time trying to break security on your uber locked down systems, they're leaving some other systems alone. If they're trying to brute force X hosts at a time, and some of them are secure, it will be longer before they move along to possibly more insecure hosts.
This reduces the rate of expansion of these annoying brute forcers
Better yet, keep the port closed to the outside world. Use port knocking with software such as Aldaba to control the ability to ssh in.
I lost a bunch of books that were precious to me in the Katherine flood in 1998
Ok, yes.. nothing is going to be completely secure. An eBook might (if it's not DRM'ed, and you have offsite backup).
I'm thinking more along the lines of: when I buy a physical book, Amazon can't delete it from my bookshelf, without me knowing.. the book won't just vanish. If I have a kindle, that's a very real possibility
I regularly have more than one book 'on the go' for entertainment purposes. Something serious for when I'm ready and willing to engage in a serious text that demands concentration
Perhaps.. but are you going to read your entire book library on the go? Most people will take one or two books on the go, unless it's something rare like a long trip..
Yeaaaaahh.. Ok, that really is the killer. I've lost more books to friends than to the above flood. Including first editions. Yeah, I'm talking to *you*, Gary, you thieving fucker. Bring it back and all is forgiven. 'Loaning' a pdf or other digital format is a gift, not a loan, and you don't have to keep track of your flaky friends and their propensities to forget where they got books from.
The main problem is the publishers' DRM formats lock the book to the reader, so you either can't get the file off your reader, or when you transfer the file to your friends, they can't read, because their reader isn't "authorized".
Of course if you have plain old PDFs, matters are different...
The run out date for the RIR IP address pools has not been continuously changing to 'about to run out'. It changed exactly once, due to the adoption of a new technology and an entirely new addressing scheme (CIDR).
The 2011 run-out date was forecast by the folks who compiled the IPv4 address report work back in 2005, and the expected year of run-out has not changed. In fact, so far the model and the predictions have shown to be fairly accurate.
There has not been inconsistency or divergence between the reports and reality.
The reports are certainly more compelling than an anecdotal claim that "We've been 'about to run out' of IPV4 addresses for over 10 years."
In this case, freely allowing the purchase and sale of parts of IP blocks piecemeal would be an internet routing table disaster.
The routing table has already gone over 300,000 entries. Filtering is already a reality for many sites, and many ISPs, common equipment already can't handle the full routing table much longer at the current rate of expansion.
Equipment that can do better in hw is extremely expensive, and out of reach of much of the market.
Now, the registries today allocate blocks of IP addresses in a manner that allows filtering.
For example, if you get a /22 for multi-homing, that block gets allocated from a block from which only /22's are allocated. That way, everyone can filter to the /22, you advertise one /22 route, if you try to break up that /22 and advertise 4 /24 routes, for traffic engineering, you can do it, but many sites will filter it.
The same applies to organizations who get a /20 direct assignment, they can chop up their /20 into 16 /24s and also advertise each one with different values or from different places for traffic engineering, and it's common to chop that up a bit, but most sites will filter those, and only their /20 announcement is propagated.
Now, imagine if policies were different, and you got a /19 you later didn't need half it. You are supposed to return the /20 you don't need to the registry and exchange keep only the smaller block if this happens.
But imagine you didn't... you sold 16 /24s (256 IPs each) to 16 different entities.
Now they each want to announce them (they're not connected to you)... that's 16 more entries in the routing table.
Ok, that matters but is not massive.
What is HUGE is the fact that when people apply their filtering rules (accepting only /20 or larger) advertisements from your block allocated from a block from which only /20s are allocated.....
Suddenly those networks you 'sold' those blocks to aren't reachable by networks in the DFZ that do this filtering.
And they'll be complaining to them, demanding they relax their filtering, which ultimately causes costs to be massively increased for everyone, or their equipment blows up, or they tell the people you sold IPs to to go get a proper block... in any case, the result is bad for the community
Even though you benefit from selling IPs, and they benefit from being able to get them from you, the community as a whole incurs a massive expense, it's basically an abuse of the commons.
Yes, there was a serious IP shortage looming 10 years ago. The issue was a boneheaded allocation strategy that provided most users more IPs than they needed. Everything was either a number of /24s, a /16, or a /8.
The introduction of CIDR bought some time, because it made allocation as efficient as it can be in IPv4.
The EU Commission's report was not credible.
The IPv4 Address Report is.
This is not the sky falling, this is the big fat meteor inching down bit by bit. It finally hits, and causes epic cataclysm, sometime in 2011.
It's a bit like suggesting you can sell parts of your land (real-estate) under the table, without notifying the county records office of the sale..
The problem is... there's a registered owner (or deed holder). And having someone tell you that you can use some IP addresses is useless unless you can get traffic to them.
The action required to get traffic to go to an IP address is very public, you have to announce the IP address space using an AS number.
The only way for you to do it without setting off alarm bells is to pretend that you ARE the person you "bought" the IPs from under the table, using their AS number.
Your announcement will probably be filtered, since your IP block is a portion of theirs (it's smaller than the assignment)
So the traffic goes to them... unless they happen to be an ISP connected to you, you are now in a sticky situation.
So the difficulty in simply 'acquiring IPs' under the table, is the need to get connectivity to them. Controlling that connectivity is harder, and if the company that sold you the IPs goes bankrupt, you're screwed.
You're better off just getting your ISP to allocate you the IPs. Either that... or buying/merging with other companies for the sole purpose of acquiring their IP addresses, and throwing away all else.
(Depending on how scarce IPs get)
Ok... what's the band-aid solution the CEOs use when the Enterprise SQL server has less than 10GB of disk space remaining on its data drive, and business requirements demand that approximately 1GB of new data be stored every day (transaction records) ?
Are you suggesting the businesspeople won't authorize the storage system be upgraded or changed to allow more storage capacity?
There's really no inexpensive band-aid solution that effectively lets you get around IP exhaustion.
Maybe with the right type of gateway they could.
Imagine you reserve a /16 of "private address space" for name mapping.
You have a gateway that provides DNS.
When someone looks up "www.blah.com" and it has an IPv6 address, the DNS server immediately allocates an ephemeral IPv4 address, enters it into a temporary database, and returns it to the client.
Now when the client requests to open a TCP connection to the ephemeral IP address within the TTL period, the gateway will automatically receive the IPv4 packet, re-encapsulate it as an IPv6 packet with the proper destination address. Upon receiving a reply packet, it will find the matching database entry, re-encapsulate it as an IPv4 packet, and return the reply to the client.
The result is a user-transparent conversion from V4 to V6 and from V6 to V4.
The service they promise (sort of)... but they're being *******'es about it. If I understand correctly they provide article author two options (1) Use Verizon IP addresses, or (2) Use their ARIN assignment and peer with Verizon AS 701.
Where Verizon blocks announcements of prefixes longer than /32.
This is a long-standing (braindead) policy on Verizon's part, that doesn't even account for the fact that RIRs are handing out /48 PI assignments in some cases, and there can be multi-homed sites with /56s.
In other words, a third of the V6 internet. You can think of this as the IPv4 equivallent of only accepting announcement of a /19 or larger block of IP addresses.
Verizon isn't well known for having complete IPv6 connectivity, a lot of "IPv6 providers" don't. If you are serious about V6 connectivity, you definitely want to get multiple providers.
In the V6 world, connectivity is sparse, and filtering is overly aggressive from the likes of Verizon and other big V4 players, almost as if they're not really all that serious about ensuring global V6 reachability. I would say 2 or 3 transit providers is needed for bare minimum connectivity. And naturally it's better if you can peer with others...
Reselling IP addresses is exceedingly difficult unless you do it under the table.
Strictly speaking, it's explicitly not allowed in most regions.
That would be OLTPC or OLNATPC
Actually, n/m, come to think of it.. many to one translations are commonly called PAT, NAPT, PNAT, or "Overload NAT".
Oh, and though it may be a matter of debate, some folks swear that it's incorrect to call those NAT.
So OLPPC (One layer of PAT per citizen) or OLNPPC (One layer of Network and Port Address translation per citizen), OLNAPTPC, or respectively OLNAPTC OLPNATPC, or OLNPC
But not OLPC...
Oh, what were we talking about again?
IPv4 Exhaustion is expected approximately 734 days from today's date. That is just about 2 years.
It takes a lot longer than 2 years to develop a networking standard, and gain acceptance from the community, and no alternative has even been proposed.
There are two solutions on the table: IPv6 and IPv4 with carrier grade NAT.
It's going to be one of those things, in two years.
Yes, but they will have to pay for two seats..
3) If you have a large enough build process, you may have modules getting compiled from different machines. Guess what happens if not all of the machines have gotten updated yet?
You never update build machines without qualifying those updates first. And once you've qualified them, you stop all build processes until update is finished, roll out the update to all machines immediately.
Re-test complete build, and if it doesn't work out, you take your backup plan and revert the update.