[137273] in North American Network Operators' Group
Re: Looking for an IPv6 naysayer...
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Feb 10 15:15:33 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4D53FDA2.8050304@nic-naa.net>
Date: Thu, 10 Feb 2011 12:09:39 -0800
To: Eric Brunner-Williams <brunner@nic-naa.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 10, 2011, at 7:00 AM, Eric Brunner-Williams wrote:
> On 2/9/11 10:32 PM, Owen DeLong wrote:
>>=20
>> On Feb 9, 2011, at 3:08 PM, Eric Brunner-Williams wrote:
>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>> 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.
>=20
> "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...
>=20
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.
>=20
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.
>>>=20
>> You do not have to abandon v4 to deploy v6. That's an absurd claim.
>=20
> 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.
>=20
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 ...
>>>=20
>> Again, the need for v6 is not predicated on the abandonment of v4.
>=20
> 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.
>=20
> 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.
>=20
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.
>>>=20
>> I believe AfriNIC has a /12 like any other RIR. I'm not sure what you =
are saying here.
>=20
> 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.
>=20
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.
>>>=20
>>> if the window for applications opens 4 months after icann-41 (amman, =
jordan), in q42011, then delegations will occur as soon as q32012.
>>>=20
>> Yes.
>>=20
>>> 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?
>>>=20
>> I'm not sure what you mean by _sparce_.
>=20
> See africa, v6 availability, above.
>=20
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.
>=20
> 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?
>=20
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?
>=20
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"?
>=20
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.
>=20
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.
>=20
> see above.
See answers above.
>>=20
>>> 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.
>>>=20
>> 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.
>=20
> 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.
>=20
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.
>=20
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".
>=20
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.
>>>=20
>> I don't think that 1q2012 is especially out of line given a 2q2012 =
target date.
>>=20
>>> 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.
>>>=20
>> 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?
>=20
> just how many endpoint identifiers do you think a registry requires?
>=20
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.
>=20
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.
>=20
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.
>=20
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
>>>=20
>> Any time.
>=20
> less religion, more near-term numbers. t.i.a.
>=20
No problem.
Owen
