The idea's been done, eg http://www.gogo6.com/gogoware/gogocpe.
Not quite down to $30 there, but it'd be fairly easy to roll custom firmware to do 6rd or similar on a raspberry pi or beaglebone black at about that price point. Finding the business case and figuring out how to support it is the part that gets tricky.
-e
I could only wish the biggest software barrier to disabling IPv4 on local networks was XP's DNS resolver path.
Doing away with IPv4 isn't a sane short-term goal for anyone carrying along software as old as XP anyway; I'd focus on getting IPv6 to all of the things and marginalizing IPv4 destinations to the point that CGN is of reduced impact and concern.
Oh, and a pony.
Jima
No. You just need to install a caching nameserver or a simple v4/v6 relay.
Mark
Doing away with IPv4 isn't a sane short-term goal for anyone
who wants global internet connectivity/reachability, period.
folk who advocate disconnecting from ipv4 should lead by example or
stfu. either way, it would reduce the drivel level.
randy
Doing away with IPv4 isn't a sane short-term goal for anyone
who wants global internet connectivity/reachability, period.
Breaking global connectivity is bad. I don't see networks turning off ipv4.
I would favor differentiation of network characteristics -- eg
Make IPv4 a service just for bulk transfer applications.
make IPv6 the best choice for interactive applications.
-- for example: large Cable providers getting together and agreeing to
implement a 100ms RTT latency penalty for IPv4; in other words,
heavy buffering of IPv4 traffic, and heavy oversubscription
(Resulting in greater total performance throughput for data transfers
over Bittorrent or microtransport, but less perception of performance
for interactive applications).
This is probably what they already have, just stop trying to throttle
IPv4 users, so to encourage IPv6 adoption -- they just need to make
have some high capacity IPv6 only links, and make it an uncongested
service, that will provide additional benefits to application
developers to favor it.
Under these conditions, IPv6 service can be higher. Don't give it
away for free;
the IPv6 Cable/DSL service should have twice the cost for the end
user as the IPv4 service does, so that they feel the IPv6 service is
of value, and should include all the assistance to achieve the
greater performance.
The exhaustion of IPv4 address space also creates an inertia against
users switching around IPv4 providers (due to insufficient IP address
space available to accommodate build out of new infrastructure);
therefore, content providers would be incentivized to get people
accessing their site over IPv6.
E.g.
dedicated higher-capacity links for IPv6, and less buffering to
minimize latency, that way web sites initially get an incentive to
become IPv6-enabled destinations, in the form of perceived
improvements in performance;
without breaking connectivity.
etc. etc.
-- for example: large Cable providers getting together and agreeing to
implement a 100ms RTT latency penalty for IPv4
we do not see intentionally damaging our customers as a big sales
feature. but we think all our competitors should do so.
randy
-- for example: large Cable providers getting together and agreeing to
implement a 100ms RTT latency penalty for IPv4we do not see intentionally damaging our customers as a big sales
feature. but we think all our competitors should do so.
Yes, I do realize, that because IPv6 is an external benefit
situation, where on the whole the public avoids pain and then
benefits on the whole, with IPv6 adoption, but for the benefits to be
obtained, an internal cost is required with no individual benefit
for a network user (or provider), the actors that would need to
participate: no individual ISP should currently see it as a big sales
feature to make their IPv4 service worse, and no end user should see
IPv6 as something they need to jump on.
But nonetheless, there are ISPs that have undergone the cost to become
IPv6-enabled.
So at least, there is (at some level), in some cases, a potential
willingness of providers
to make some sacrifices that ultimately provide greater benefit to
the network community.
So something like penalize IPv4, or disconnect from IPv4, or
government mandated IPv6, begin to sound like a good idea, only
because there aren't better options, to persuade end users to ignore
short-term pains, adopt IPv6, and let everyone derive the
long-term benefits of IPv6.
I don't see turning IPv4 off as a short-term goal for anyone.
OTOH, I do see the cost of maintaining residential IPv4 service escalating over about the next 5-7 years.
Lee Howard sees roughly the same thing. (He has fancier math and better statistics than I used).
Bottom line, it is unlikely that $residential_price will be sufficient to sustain residential IPv4 service(s) beyond about 2018. The biggest question in that equation will be what percentage of residential users are behind the unmaintainable CGN solutions and what percentage retain service similar to the current (sad) state of affairs. For the customers in the latter category, they might be able to continue until their addresses are needed for more profitable services.
Owen
Yes... Which I interpret to result in an outcome of less service,
for more cost, for residential users, eventually, as long as IPv4
addresses remain demanded in a quantity greater than the number
available.
Either (a) CGN, or (b) Fewer IPv4 subscriptions at higher price per
subscription, than would otherwise occured (if IPv4 addresses were
not scarce).
Is there another possible outcome for residential IPv4 experience that
you see as likely?
(Either of those two scenarios is most likely to result in less
connectivity, fewer network users, higher cost, and worst service per
user..)
On the other hand... price tag $X for IPv6+IPv4, no option for
just IPv4, and price tag $X / 2 for just IPv6.
Could provide motivation for the residential users (and their
destinations) to move towards IPv6. Once a large enough quantity
had moved towards IPv6 only, the price could return to $X for IPv6
only.
And the price difference could be structured in other forms (not
necessarily as a subscription price difference), it could take a
non-monetary form, such as increased privilege, or more bandwidth
(greater throughput, higher cap) for IPv6 only users, etc.
-- for example: large Cable providers getting together and agreeing to
implement a 100ms RTT latency penalty for IPv4we do not see intentionally damaging our customers as a big sales
feature. but we think all our competitors should do so.
This business is hard enough without deliberately breaking the customers.
I don't see turning IPv4 off as a short-term goal for anyone.
OTOH, I do see the cost of maintaining residential IPv4 service escalating
over about the next 5-7 years.Yes... Which I interpret to result in an outcome of less service,
for more cost, for residential users, eventually, as long as IPv4
addresses remain demanded in a quantity greater than the number
available.
The math says that won't work out well. Looks like it is far more economical
for residential providers to simply stop providing IPv4 to any customer that
chooses not to pay a premium for it (steep premium at that).
Either (a) CGN, or (b) Fewer IPv4 subscriptions at higher price per
subscription, than would otherwise occured (if IPv4 addresses were
not scarce).
Yep.
Is there another possible outcome for residential IPv4 experience that
you see as likely?
Depends. Unless there is sufficient mass of residential subscribers willing
to pay the premium for CGN (unlikely in my estimation), it'll make the most
sense for residential providers to simply turn off IPv4 services and tell laggard
web sites like Amazon that they are SOL in terms of getting further business
from those customers.
(Either of those two scenarios is most likely to result in less
connectivity, fewer network users, higher cost, and worst service per
user..)
Briefly… Shortly thereafter, it will result in a mad dash by the afflicted content
providers to get their act together with IPv6.
On the other hand... price tag $X for IPv6+IPv4, no option for
just IPv4, and price tag $X / 2 for just IPv6.
Well, either way you look at it (I think in terms of $X for IPv6, $X*2 for
dual-stack) where $X is close to what you pay today. The math works
out the same, roughly.
Could provide motivation for the residential users (and their
destinations) to move towards IPv6. Once a large enough quantity
had moved towards IPv6 only, the price could return to $X for IPv6
only.
The destinations are the actual problem. The residential users don't care
all that much as long as they can reach their destinations. The only remaining
problem once the destinations are addressed are the consumer electronics
that lack IPv6 support. That's a much easier problem to work around.
And the price difference could be structured in other forms (not
necessarily as a subscription price difference), it could take a
non-monetary form, such as increased privilege, or more bandwidth
(greater throughput, higher cap) for IPv6 only users, etc.
Probably not. It's the cost of providing IPv4 services that will escalate. As
such, to do what you are suggesting, they'd have to raise everyone's
subscription prices at the same time as well.
Owen
CGN isn't that bad, and if you set up an acceptable opt-out method, it should work fine. Some things haven't changed much. A majority of my customers have no need for services that NAT44 or NAT444 break in a noticeable way. In the same regard, I can cut their number of simultaneous connections drastically if need be(but 16k gains me 4:1). As long as their Facebook apps work, they most likely won't notice to opt out.
If I get 25% on CGN, I gain years of IPv4 reuse. If I succeed at 50%+, I suspect I'll survive the cutover.
Of course, I don't believe anyone should consider CGN without IPv6 support. It has the potential of keeping people from noticing the CGN as p2p apps support IPv6.
The only thing I haven't liked is that it looks like I'll have to have the customer reboot after the opt-out for their IPv4 address reassignment (or wait it out). One CGN deployment method I'm considering is flow analysis of the customer traffic and automatically opting out customers which analysis shows will definitely not work. This analysis works best post dual stack deployment which isn't a problem for me.
I'm extremely happy with deterministic port block allocation(based on http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-05?). Thankfully, I won't have to keep a log of every connection. I don't mind exporting flows for analysis, but I don't want to keep 1-2 years of them.
Jack
Depends. Unless there is sufficient mass of residential subscribers willing to pay the premium for CGN (unlikely in my estimation), it'll make the most sense for residential providers to simply turn off IPv4 services and tell laggard web sites like Amazon that they are SOL in terms of getting further business from those customers.
CGN isn't that bad, and if you set up an acceptable opt-out method, it should work fine. Some things haven't changed much. A majority of my customers have no need for services that NAT44 or NAT444 break in a noticeable way. In the same regard, I can cut their number of simultaneous connections drastically if need be(but 16k gains me 4:1). As long as their Facebook apps work, they most likely won't notice to opt out.
It's not a question of how bad it is (I think it actually is, but that's another discussion altogether). It's a matter of how much it costs to maintain it on an ongoing basis. The real world numbers, especially when you count up the technical support calls that are expected are pretty nasty from a "we want to make a profit selling this" perspective.
When you say a majority of customers, I think you are mistaken. The majority of services do not break. However, the vast majority of customers use at least one thing today that does break. Play Station Network, for example, doesn't do well with CGN. Yelp, for example, won't do well with CGN in terms of its geolocation proclivities. Depending on where you live and where you get CGN'd you may get interesting results with some banking institutions, Netflix, and some other things as a result of their geolocation proclivities. Google maps may or may not break in interesting ways depending on load on the CGN server and other factors. The list goes on.
A single tech support call from a customer cancels out the margin for approximately 5 months of service, so even if you only break 20% of the customers to the point of creating a tech support call each month, you lose.
If I get 25% on CGN, I gain years of IPv4 reuse. If I succeed at 50%+, I suspect I'll survive the cutover.
Best of luck with that strategy. I think this ignores the growing IPv4 demand that will be coming from your business customers and assumes that your residential customers are all that you have to stack onto these addresses.
Of course, I don't believe anyone should consider CGN without IPv6 support. It has the potential of keeping people from noticing the CGN as p2p apps support IPv6.
The more things support IPv6, the less painful CGN will be. This is certain.
The only thing I haven't liked is that it looks like I'll have to have the customer reboot after the opt-out for their IPv4 address reassignment (or wait it out). One CGN deployment method I'm considering is flow analysis of the customer traffic and automatically opting out customers which analysis shows will definitely not work. This analysis works best post dual stack deployment which isn't a problem for me.
Telling a customer to reboot a router (or a single host) isn't all that bad. After all, they probably did that at least 5 times at the behest of your front-line support folks before they reached someone that understood the problem anyway. (At least that's been my general experience with most residential providers).
I'm extremely happy with deterministic port block allocation(based on draft-donley-behave-deterministic-cgn-05). Thankfully, I won't have to keep a log of every connection. I don't mind exporting flows for analysis, but I don't want to keep 1-2 years of them.
Or 7, as required by CALEA. The problem with draft-donely is that customers that exceed the expected number of ports run into issues (or additional logging required), so you either don't get the best efficiency out of your addresses, or you get problems in other ways.
Owen
Best of luck with that strategy. I think this ignores the growing IPv4 demand that will be coming from your business customers and assumes that your residential customers are all that you have to stack onto these addresses.
The residential currently eats up a majority of my addresses, so the more I can recover from them for business customers, the better.
Telling a customer to reboot a router (or a single host) isn't all that bad. After all, they probably did that at least 5 times at the behest of your front-line support folks before they reached someone that understood the problem anyway. (At least that's been my general experience with most residential providers).
Perhaps my viewpoint is different, given that I only have two lines of support folk, and talking to me is a rarity for a customer. 
Or 7, as required by CALEA. The problem with draft-donely is that customers that exceed the expected number of ports run into issues (or additional logging required), so you either don't get the best efficiency out of your addresses, or you get problems in other ways. Owen
That problem was mentioned on v6ops, and the general lesson that I took from it is to not exceed 16:1 ratio if it can be helped. 4k ports should be fine. 64:1 is probably sustainable for a lot of customers with 1k ports, but there will be a percentage that will have issues. Luckily, most of those with issues are usually running services that require opt-out anyways.
If I calculate correctly, even at 20% of my residential(70% of total allocated) on CGN, I'm regaining 18% of my residential assignments with a 16:1 ratio. I could conservatively figure a years worth of my usual allocation has been saved. If I can push better numbers, I'll get more years.
Jack
Best of luck with that strategy. I think this ignores the growing IPv4 demand that will be coming from your business customers and assumes that your residential customers are all that you have to stack onto these addresses.
The residential currently eats up a majority of my addresses, so the more I can recover from them for business customers, the better.
Point is that your business customers probably won't be so CGN tolerant and growth there will reduce the ability to multiply residential customers on recovered addresses.
Telling a customer to reboot a router (or a single host) isn't all that bad. After all, they probably did that at least 5 times at the behest of your front-line support folks before they reached someone that understood the problem anyway. (At least that's been my general experience with most residential providers).
Perhaps my viewpoint is different, given that I only have two lines of support folk, and talking to me is a rarity for a customer.
I was speaking from the customer perspective. In addition to working for an ISP, I'm also a customer of multiple residential providers and have experience with a number of former providers as well.
Or 7, as required by CALEA. The problem with draft-donely is that customers that exceed the expected number of ports run into issues (or additional logging required), so you either don't get the best efficiency out of your addresses, or you get problems in other ways. Owen
That problem was mentioned on v6ops, and the general lesson that I took from it is to not exceed 16:1 ratio if it can be helped. 4k ports should be fine. 64:1 is probably sustainable for a lot of customers with 1k ports, but there will be a percentage that will have issues. Luckily, most of those with issues are usually running services that require opt-out anyways.
Hmmm… Thinking just about my active usage, 4k ports divvied up among the 15 or so IP-speaking hosts in my house works out to just under 300 ports per host.
That's probably sufficient for relatively light usage. It would probably suck pretty bad on days when I'm doing a lot.
If I calculate correctly, even at 20% of my residential(70% of total allocated) on CGN, I'm regaining 18% of my residential assignments with a 16:1 ratio. I could conservatively figure a years worth of my usual allocation has been saved. If I can push better numbers, I'll get more years.
What does the CGN cost you per subscriber (equipment, additional staff, etc.?)
Owen
In my case, very little. Equipment was covered by bandwidth usage which mandated upgrading to higher end routers that support more than I need. It looks like my trios handle NAT with their logical services, though I haven't checked on if it will hit me for licensing. A services blade wouldn't be that bad for our load levels, though. Our front line support have brains and use them. We have a fair margin to play in for additional support time without adding new personnel. It was more costly dealing with people being sick, on vacation, taking lunch, etc.
Of course, we maintain 8 people in the helpdesk for only 30k residential. Scale does matter. I just happen to be in what I'd consider a sweet spot. I'm just over the point where I had to dish out money for an upgrade that will likely last me 10+ years minus EOL/software/technology issues but was cost factored for the standard 5 years.
If the existing cards handle CGN without additional licensing, then the only real cost is personal, my sanity, and the company need/will not factor that in.
Jack
One thing to consider is what the new support load will be from issues dealing
with CGN causing new breakage. That might be baked into your support already,
but at larger scale it probably isn't. Maybe it's marginal, but it's worth asking.
Mike