On Feb 10, 2011, at 7:00 AM, Eric Brunner-Williams wrote:
> 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...
>
I said "at least in some cases". Since we know that it will be a monotonically
increasing set of "some cases" which will rapidly grow to
a very high fraction of "some cases", yes, it is a good motivation for a
general mandatory-to-implement requirement.
> 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.
>
We can agree to disagree about this.
>>> 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.
>
No, it is not. I am claiming that you need to have IPv6 capabilities on
critical internet infrastructure because:
+ The internet is moving to IPv6.
+ We will be out of free IPv4 addresses by the time these
services are being deployed.
+ A monotonically increasing number of clients will have no or
limited/degraded IPv4 access at or soon after deployment
of these new GTLDs.
>>> 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.
>
I never claimed that .cat failed because of lack of IPv6 as I have no first
hand knowledge of the failure of .cat.
I never claimed that .nyc would fail because of lack of IPv6.
I don't know whether either of those claims is true. If either claim is true,
then, certainly, it would be evidence that we need IPv6 for new deployments of
critical infrastructure that it is a valid requirement for new GTLDs. However,
even if both claims are false, it does not eliminate the need for new
GTLDs to provide support for IPV6.
There are no lawyers in Marina Del Rey in these statements:
+ The internet is moving to IPv6.
+ We will be out of free IPv4 addresses by the time these
services are being deployed.
+ A monotonically increasing number of clients will have no or
limited/degraded IPv4 access at or soon after deployment
of these new GTLDs.
+ In a world where there are IPv4 only, IPv4/IPv6 dual stack and
IPv6 only hosts, critical infrastructure such as GTLD
services should be required to be dual-stack.
>>> 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.
>
I guess your point is that AfriNIC and Africa in general is behind the rest of
the world in IPv6 deployment?
I'm not sure how that is relevant to the fact that IPv6 is a valid requirement
for new GTLD infrastructure other than to say
that dropping this requirement might impact Africa less than other parts of the
world.
>>>> 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.
>
Oh, you mean sparse and the_..._ is for emphasis. I thought it was offsetting
some special word. Sorry for the misunderstanding.
My claim is that if you are running GTLD services, then, you are dealing not
with any particular region, but, with providing global infrastructure.
The sparseness of IPv6 infrastructure in Africa is not particularly relevant to
the question of whether or not global infrastructure needs to support
IPv6 going forward.
>> 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?
>
Are you serious? If it's not, then we don't really need GTLDs at all, do we?
> 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?
>
I never said existing gtld registries don't have such an affirmative duty. I
think ICANN severely erred in not including IPv6 in the provisions of earlier
contracts. I have said that before this topic ever came up. The fact that ICANN
made a mistake previously does not mean we should expand
that mistake or continue making that mistake.
> 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"?
>
What? I'm not trying to partition anything. I'm trying to make sure that any
new GTLDs support access from the entire internet and not just the limited
and diminishing proportion of the internet that has IPv4 going forward.
> 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.
>
I absolutely think that existing v4-reachable-only registries must be v6
reachable or fail. They may not fail quite so immediately, but, again,
I absolutely believe ICANN erred in not making this a requirement for those
registries. I certainly don't see using a previous mistake as
a reason that we should extend or expand that mistake to new registries.
>> As such, I think that registries spinning up in 3q2012 should be required to
>> have IPv6 support. yes.
>
> see above.
See answers 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.
>
We're talking about GTLD registries, not African CCTLD registries.
GTLDs are GLOBAL. Look at the v4 exhaustion graphs for APNIC, ARIN, and RIPE.
The fact that you can point to a single region that some prognosticators say
will have space for a few years longer than everyone else
really isn't a relevant argument against the need for GTLDs to support IPv6.
> 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.
>
Again, not seeing relevance here. I have no belief that registries don't need
IPv4 support. GTLD registries should absolutely be required to support
both protocols until such time as IPv4 can be deprecated in general.
> 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".
>
I really don't see how that is relevant to whether GTLD registries should be
required to have IPv6 support or not.
Regardless of where the registry is based, they are providing a global service.
They should be required to support the global internet.
>>> 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 know. I presume that they need a handful for DNS servers, some for web
servers, some for miscellaneous infrastructure.
> 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.
>
You're right. For the time being, it probably won't be hard for them to obtain
IPv4 resources and that really isn't relevant to
whether or not they need to provide services over IPv6. The relevant part is
the number of potential people trying to use
their services that may not have IPv4 access.
> 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.
>
As I said. I think that registries should be required to support both protocols
as a simple matter of compatibility with the state of the global
internet during the time of their service. It would be absurd to allow a
registry with support only for IPX. A such, in the internet that will
exist during the terms of these contracts, it would be absurd to allow a
registry without support for both IPv4 and IPv6. However, I can
see the possibility of a case where a registry is actually unable to get
sufficient IPv4 resources during the contract period. In such a case,
I do not believe that inability should be held against them. However, with
regards to IPv6, there is no such excuse.
> 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.
>
The case for benefit is not there yet. However, as you pointed out, everything
we're talking about is 18-24 months away from operations, so,
the case will change a lot in that time.
The case that is there now is the fact that we all know the internet is
changing and that IPv4 addresses are becoming scarce. Deployment
of critical infrastructure without dual stack (or at least IPv6) support at
this point is irresponsible going forward.
>>> thanks for your difference,
>>> -e
>>>
>> Any time.
>
> less religion, more near-term numbers. t.i.a.
>
No problem.
Owen
