Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
"Necessity is the mother of invention" - old adage
Basic economics has always indicated that there would be industry no change from v4 to v6 until it was necessary, and the only real necessity for doing so is the exhaustion of IPv4 addresses. So I don't think that the lack of industry deployment of v6 until now should be a surprise, and neither does it mean it has "failed" - I believe it has been simply a case of waiting for the right time, and that time should be from the RIR exhaustion over the next 12 months.
Nothing would drive IPv6 adoption faster than useful content only being available via v6, which would force customers to demand their (internet and application) providers make that content available somehow, driving the providers towards v6. Of course, it is too soon right now to make content IPv6-only, because an insignificant number of people would be able to access it, and therefore its availability could never be known by the general Internet community.
But if content providers are able for many years yet to get enough small amounts of IPv4 addresses to make their content available via IPv4 (even if dual-stacked with v6), then this risks removing much of the industry driver towards IPv6 adoption, and that scenario would be likely to create artificial commerce, black markets and exorbitant effective pricing in v4 addresses, and would favour providers with well-established v4 networks.
So this is another issue I have with the current final /8 policy; I think it's a reasonable idea to have enough addresses for specific purposes for a couple of years while the transition to v6 gets under way properly, but if either it promotes a lengthy availability of IPv4 for new content servers (thus potentially removing IPv6 adoption drivers and increasing IPv4 address value), or it causes an explosion of requests artificially tailored to bypass the intent of the policy (thus potentially causing an inappropriate distribution of addresses anyway, with unnecessary hostmaster workload and impacts upon routing tables, etc.), then I feel it may do more harm than good for the industry.
So the question in this context is what the correct balance in size of space to reserve? The current policy suggests a /8; prop-091 suggests another view.
Regards, David
On Jan 24, 2011, at 5:58 PM, David Woodgate wrote:
"Necessity is the mother of invention" - old adage
Basic economics has always indicated that there would be industry no change from v4 to v6 until it was necessary, and the only real necessity for doing so is the exhaustion of IPv4 addresses. So I don't think that the lack of industry deployment of v6 until now should be a surprise, and neither does it mean it has "failed" - I believe it has been simply a case of waiting for the right time, and that time should be from the RIR exhaustion over the next 12 months.
Nothing would drive IPv6 adoption faster than useful content only being available via v6, which would force customers to demand their (internet and application) providers make that content available somehow, driving the providers towards v6. Of course, it is too soon right now to make content IPv6-only, because an insignificant number of people would be able to access it, and therefore its availability could never be known by the general Internet community.
It would, however, be interesting to see some leading content provider get brave and announce the date (some time in the future) by which they intend to turn off IPv4 (at least for some period of time).
Imagine, for example if $SOCIAL_NETWORK were to announce that effective January 1, 2013, they would be turning off IPv4 access to their services for a period of 2 weeks. Users that do not yet have IPv6 (click here to see if you have IPv6 yet) should contact their ISP to arrange for this upgrade.
Unfortunately, the reality of economics also says that it's unlikely any $CONTENT_PROVIDER will get that brave until there is a much more significant IPv6 deployed base. Heck, there are some that are still hesitating to turn on IPv6 access to the general public because they might have a problem with as much as 0.05% of users.
But if content providers are able for many years yet to get enough small amounts of IPv4 addresses to make their content available via IPv4 (even if dual-stacked with v6), then this risks removing much of the industry driver towards IPv6 adoption, and that scenario would be likely to create artificial commerce, black markets and exorbitant effective pricing in v4 addresses, and would favour providers with well-established v4 networks.
I think it is the eyeballs that will be motivated to move first, unfortunately. Content would be a great motivator for the eyeballs, but, content isn't motivated to move until the eyeballs do. (Which is unfortunate because if content had moved first, we'd be facing a much smoother transition).
However, the eyeball networks simply can't sustain their growth models and services without an influx of new addresses on a continuing basis. Those addresses in a market for IPv4 will be cost prohibitive compared to the economics of residential access. So, eyeball providers will be forced to deploy a combination of IPv6 and NAT444. The end result of this deployment will be a situation where content providers will have users complaining of degraded user experiences over NAT444 until they implement IPv6. This will drive the content providers to IPv6.
This is the rough road we have ahead of us. The more content providers that get in front of this NAT444 deployment with IPv6 sooner, the more we can even out the surface of the road.
Of course there is also the potential issue that some access providers will deploy NAT444 without bothering to deploy IPv6 to their customers. I'm hoping that scenario will be rare enough that customers just move to the ISPs that offer IPv6. However, even in that case, there will be tunneled access to IPv6 solutions available to those users which will still make content accessible over IPv6 a better alternative to IPv4 content via NAT444.
So this is another issue I have with the current final /8 policy; I think it's a reasonable idea to have enough addresses for specific purposes for a couple of years while the transition to v6 gets under way properly, but if either it promotes a lengthy availability of IPv4 for new content servers (thus potentially removing IPv6 adoption drivers and increasing IPv4 address value), or it causes an explosion of requests artificially tailored to bypass the intent of the policy (thus potentially causing an inappropriate distribution of addresses anyway, with unnecessary hostmaster workload and impacts upon routing tables, etc.), then I feel it may do more harm than good for the industry.
Yep.
So the question in this context is what the correct balance in size of space to reserve? The current policy suggests a /8; prop-091 suggests another view.
With statistics to back up that view. The alternative to make the existing policy palatable from a statistical perspective would be to change the limit size to /21 instead of /22.
Owen
On 25/01/2011, at 12:28 PM, David Woodgate wrote:
...
So this is another issue I have with the current final /8 policy; I think it's a reasonable idea to have enough addresses for specific purposes for a couple of years while the transition to v6 gets under way properly, but if either it promotes a lengthy availability of IPv4 for new content servers (thus potentially removing IPv6 adoption drivers and increasing IPv4 address value)
I don't think the "supply" side (Content) is or is going to be the issue. The issue is the eyeball/access side. Reducing the space to a /8 to allow the eyeball side to continue to avoid the IPv6 issue does more harm. The issue the content providers have with turning IPv6 on is the concern about the 0.05% of people with broken IPv6 connectivity due to broken CPE. If the eyeball side gets on with providing working IPv6 connectivity then the content side seems willing to turn it on quickly.
The IPv6 day coming up shows that a majority of content is capable of turning IPv6 on - by the time you have Google, Yahoo, Akamai doing IPv6 then a big percentage of an eyeball's content will be IPv6 capable. Yet, in my country, only one of the top 10 providers appears to be interested in dual stack to the eyeballs. Indeed, the largest 4 have negligible or no IPv6 deployment.
, or it causes an explosion of requests artificially tailored to bypass the intent of the policy (thus potentially causing an inappropriate distribution of addresses anyway, with unnecessary hostmaster workload and impacts upon routing tables, etc.), then I feel it may do more harm than good for the industry.
Maybe prop-91 should give way to a proposal to tackle that issue? Reducing /8 to /9 doesn't seem to be a plan or a solution to that problem. It appears to be a way of extending IPv4 at the expensive of transition later.
So the question in this context is what the correct balance in size of space to reserve? The current policy suggests a /8; prop-091 suggests another view.
The issues for me are:
Changing the amount of space, without regard to how it's fairly allocated is an issue for me with prop-91.
Changing the amount of space based on past behaviour without considering how behaviour of APNIC members and new members will change over the next few years is an issue with prop-91.
Mean that prop-91 isn't supportable in it's current form.
MMC
Regards, David
On Jan 24, 2011, at 7:21 PM, Matthew Moyle-Croft wrote:
On 25/01/2011, at 12:28 PM, David Woodgate wrote:
...
So this is another issue I have with the current final /8 policy; I think it's a reasonable idea to have enough addresses for specific purposes for a couple of years while the transition to v6 gets under way properly, but if either it promotes a lengthy availability of IPv4 for new content servers (thus potentially removing IPv6 adoption drivers and increasing IPv4 address value)
I don't think the "supply" side (Content) is or is going to be the issue. The issue is the eyeball/access side. Reducing the space to a /8 to allow the eyeball side to continue to avoid the IPv6 issue does more harm. The issue the content providers have with turning IPv6 on is the concern about the 0.05% of people with broken IPv6 connectivity due to broken CPE. If the eyeball side gets on with providing working IPv6 connectivity then the content side seems willing to turn it on quickly.
The /9 is a piddly drop in the bucket for the access side. It won't change the runout date for access by any significant amount of time. There's no significant harm here in terms of allowing access to continue avoiding the issue.
The IPv6 day coming up shows that a majority of content is capable of turning IPv6 on - by the time you have Google, Yahoo, Akamai doing IPv6 then a big percentage of an eyeball's content will be IPv6 capable. Yet, in my country, only one of the top 10 providers appears to be interested in dual stack to the eyeballs. Indeed, the largest 4 have negligible or no IPv6 deployment.
Um, no, it shows that a collection of content providers are capable of turning IPv6 on. So far, of the Alexa top 10, 5 are planning to participate in IPv6 day. When you can show 100 of the top 100 or 1000 of the top 10,000 you start to approach the "majority of content".
, or it causes an explosion of requests artificially tailored to bypass the intent of the policy (thus potentially causing an inappropriate distribution of addresses anyway, with unnecessary hostmaster workload and impacts upon routing tables, etc.), then I feel it may do more harm than good for the industry.
Maybe prop-91 should give way to a proposal to tackle that issue? Reducing /8 to /9 doesn't seem to be a plan or a solution to that problem. It appears to be a way of extending IPv4 at the expensive of transition later.
I'm not seeing what transition you think is somehow enabled by addresses held on a shelf where nobody can reach them. Can you please explain what aspect of transition is improved by this mechanism?
So the question in this context is what the correct balance in size of space to reserve? The current policy suggests a /8; prop-091 suggests another view.
The issues for me are:
Changing the amount of space, without regard to how it's fairly allocated is an issue for me with prop-91.
It would be fairly allocated just like all the other IPv4 space not subject to this relatively new special policy. It would be fairly allocated just like the majority of IPv4 space. That how is a solved problem.
Changing the amount of space based on past behaviour without considering how behaviour of APNIC members and new members will change over the next few years is an issue with prop-91.
Considered... The existing policy will force them to behave in a manner contrary to policy if we don't amend it. I would rather see policy address the needs of the community to the extent that it can and avoid creating a situation where the community has to work around or against policy out of necessity whenever possible.
Mean that prop-91 isn't supportable in it's current form.
Sure it is... I support prop-91 in its current form.
Owen
On 25/01/2011 4:21 p.m., Matthew Moyle-Croft wrote:
So this is another issue I have with the current final /8 policy; I think it's a reasonable idea to have enough addresses for specific purposes for a couple of years while the transition to v6 gets under way properly, but if either it promotes a lengthy availability of IPv4 for new content servers (thus potentially removing IPv6 adoption drivers and increasing IPv4 address value)
I don't think the "supply" side (Content) is or is going to be the issue. The issue is the eyeball/access side. Reducing the space to a /8 to allow the eyeball side to continue to avoid the IPv6 issue does more harm.
Watching the migrations and movements and planning going on in the content side, I think it's pretty clear that dual stack is the way people are going. No one will be turning off IPv4 over their content. They're all moving at different paces but they'll all get there. I think we'll find that, in time, critical internet systems (ie. systems where inter network connectivity is critical, like mail, as opposed to more loaclised functions like remote access) will require IPv4 and IPv6 so they can exchange data in the new world and in the old world. I imagine some parts of the old world, like countries that are still buying second hand IPv4 only kit, will be some time off adding IPv6 to their systems.
In this world new entrants will need a small amount of IPv4 to ensure their spam can arrive from [unspecified old world country], and they'll need it for a considerable amount of time to come. However existing players will dual stack content and access. So existing IPv4 holders will move their IPv4 to critical internet systems and use IPv6 for pretty much everything else. They'll end up with surplus IPv4 and it'll be next to worthless, except for reallocation out to new entrants.
I think the losers here will be the folks with large pools of connectivity customers who delay rolling out IPv6 and a few 6to4 gateways. They'll pay the earth for old tech (IPv4), which they'll waste on connectivity pools and will only give them a limited time extension.
I cannot support a proposal that appears to offer a glimmer of hope to those organisations that are too set in their ways to see the world moving on around them, at the expense of ensuring inter network connectivity end to end for critical internet systems worldwide, for both future and existing address space holders.
I do not support this proposal.
Cheers, Gerard
Activity Summary
- 4698 days inactive
- 4698 days old
- sig-policy@lists.apnic.net
- 4 participants
- 4 comments