On 2/9/11 10:32 PM, Owen DeLong wrote:
On Feb 9, 2011, at 3:08 PM, Eric Brunner-Williams wrote:
I disagree... I think that offering alternate name space views to the existing {b,m}illions of v4 addressed spindles requires IPv6 reachability as well since those will also be adding IPv6 capabilities in the next year or two.
so your claim is that to have a .cat, serving registrants currently using v4 provisioned hosting services, and end-users currently using v4 provisioned eyeball networks, and initially address and resources (but not names) currently extant in the com/net/org/biz/info namespaces [1], the .cat registry first has to be v6 reachable.
My claim is that about the time these zones are rolling out, the registrants currently using v4 provisioned hosting services and end users currently using v4 provisioned eyeball networks will also, at least in some cases, be using dual stack and/or v6 services.
"in some cases" is a poor motivation for a general mandatory-to-implement requirement. a "v6 where required (by other market actors than icann's legal staff in marina del rey)" form would be appropriate -- but you're making a universal claim, so on we go... inter alia, that both ends of the chain of resolution (stub resolver on an eyeball network and mapped resource in a hosting provider rack) may be using dual-stack fails to motivate why the authoritative name to address resolver must be v6 reachable.
and this claim is true because the webhosting operators, primarily in Catalonia, who have v4 now, will themselves be v6 reachable in the next year or two ... i think this requires either the existing hosting operators abandon vhosting as a service model or abandon their existing v4 allocations.
You do not have to abandon v4 to deploy v6. That's an absurd claim.
yet it is the claim you are making. the resource must be v6 reachable, and you're not offering arbitrary capriciousness of some evangelically unbalanced lawyers in a high-rise in marina del ray as a rational, so you must have a material necessity rational.
now rinse and repeat for .nyc. the claim is somehow that the market for hosting operators (ok, the hosting lines of business of godaddy, tucows, enom, netsol, ... and their downstream resellers, which is statistically likely to have 51% of all .nyc registrations), and/or (your choice) the eyeball network operators for the tri-state area, are going to either abandon vhosting as a service model or abandon their existing v4 allocations ...
Again, the need for v6 is not predicated on the abandonment of v4.
you've managed to elide responding to both (a) an actual new (in 2005) registry, with existing v4 provisioning, and (b) a pending new (in 2012) registry, again with existing v4 provisioning. i look forward to learning why .cat failed for lack of v6, and why .nyc will fail, for lack of v6, in a sentence that doesn't contain a reference to lawyers in a high-rise in marina del ray.
where the v6 ab initio convinces me some is the area i currently work on -- developing economies. nigeria is a good example, fewer than 10^^5 computers, a population of 15x10^^7, and cell phone penetration rate approaching 1 in 3. even so, the number of v6 prefixes in afnic's inventory of allocations is ... very small ... for all of africa as a region.
I believe AfriNIC has a /12 like any other RIR. I'm not sure what you are saying here.
try looking beyond what the iana has allocated to a rir, and look at what prefixes the rir has allocated. alternatively, something along the lines of trivial pursuits, name the data centers and/or eyeball networks in africa in which v6 was deployed in q42010.
It's not that I think you only serve the future. It's that we think you are failing to recognize that IPv6 is now and that what is IPv4 today will be at least dual-stack tomorrow.
if the window for applications opens 4 months after icann-41 (amman, jordan), in q42011, then delegations will occur as soon as q32012.
Yes.
is your claim that registry operators where v6 is _sparce_, and/or where v6 eyeball networks are _sparce_, two years from today, are properly failed for technical reasons, two years from today, for lack of v6 capability?
I'm not sure what you mean by _sparce_.
See africa, v6 availability, above.
My claim is that by 4q2012, I expect we will see much much wider IPv6 deployment and potentially eyeball networks that are primarily or exclusively IPv6 with at best limited or degraded IPv4 support through multiple layers of NAT.
now that is an interesting claim. suppose it is true and there is "at best limited or degraded IPv4" on eyeball networks. why is a once per session trip up and down the chain of resolution sufficient to motivate anything? further, why do you suppose that new gtld registries, but not existing gtld registries, have an affirmative duty to be v6 reachable from resolvers on v6-only eyeball networks? what is the point of partitioning content along "legacy v4 provisioned content, and its v4 provisioned access demographic" and "new gtld mapped content and its v6 provisioned access demographic"? to be really convincing, it would help if you'd make the case that existing v4-reachable-only registries must be v6 reachable or fail, just as you'd fail a new gtld applicant lacking v6.
As such, I think that registries spinning up in 3q2012 should be required to have IPv6 support. yes.
see above.
if your claim is that v6 is mandatory to implement sometime soon, i'm fine with that rather flexible temporal requirement, but icann's current rules of the road are an application that isn't v6 ready at transition to delegation (roughly two years from now) fails.
If you define soon as prior to 2q2012, then, yes, I'm fine with that. However, that seems to be about a quarter earlier than you think these things will be starting up. Since you seem to be claiming they should get some period beyond that where they don't need to run IPv6 (I'm not sure where they're supposed to get their addresses to run on IPv4 by then, frankly), I think your definition of soon and mine are probably not compatible.
first, refer to the statistical likelihood date of v4 exhaustion in the afnic region. there's a nice graph available that shows very broad shoulders, several years of availability. second, registries are critical internet infrastructure, and in the arin region prop 125, which you know about having commented on it, there exists a policy of reserve for ci requirements, and 125 provides for three (3) years of resource availability to the allocation receiving ci requester. requesting a 125-similar policy for the rir with the next most proximal statistical likelihood date of v4 exhaustion, the ripe region, is on my todo list. note however, that few applications for registries located in the arin or ripe regions, where the statistical likelihood date of v4 exhaustion is both most proximal, and the confidence level narrowest, are likely to meet the general reading of the icann board of directors' resolution #20 (nairobi), expressing an interest in forms of cost-reduction assistance to needy applicants, e.g., from "developing countries".
pessimally, the requirement is present at the date when applications are submitted, that is, a year from today.
I don't think that 1q2012 is especially out of line given a 2q2012 target date.
now there's still 24 months for icann legal staff to acquire clue, and for last week's press event to galvanize operators everywhere, so perhaps this (and its cognate, dnssec at transition to delegation) can be elided, but it is irresponsible to assert [2], independent of the purpose and position of a registry, that it must have a feature due to the universalist claims of advocates for a particular technology.
I think it is irresponsible at this point to consider deploying any major network infrastructure without requiring IPv6 capabilities at deployment. IANA is already out of IPv4. If you expect these systems to start getting deployed in 3q2012, then, you're talking about a time which is likely to be well past RIR exhaustion in most cases. I suppose they can get a /22 from APNIC, but, other than that, where do you expect these organizations to even get IPv4 to work with?
just how many endpoint identifiers do you think a registry requires? i don't think this is your best argument, as it requires a suspension of belief that there is a market, or markets, in allocations sufficient to provision anything from a half-rack to multiple racks in a standard cage, and the margin on a registry footprint is lower than the margin on most other hosting operations. if you're going to swing for the fence, don't try to argue lack of something that can still be bought for some time to come. make the claim that registrants (other than ppc registrants, that's a separate case you may want to make, and if so, don't forget the eyeball network operator as a beneficiary from systemic synthetic return, a la verisign's sitefinder) demand that their resources be resolvable by v6 only paths because there is sufficient revenue in v6 reachability, or that v6 only registrations will, in the twelve quarters of operation, provide more revenue, or at least enough to cover costs and reduce the likelihood of registry failure, than the v4 only registrations. having made any case based upon benefit, it would be illuminating to opine why no existing registry operator is experiencing v6 uptake by its registrants supporting a registrant beneficiary theory.
thanks for your difference, -e
Any time.
less religion, more near-term numbers. t.i.a. -e