Re: Looking for an IPv6 naysayer...

[Eric Brunner-Williams <brunner () nic-naa net>]

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