IPv6 survey from CAIDA

[k claffy]

hello kind 6ops-folk,
                                                           
we're trying to do some quantitative modeling of                               
the IPv4->IPv6 transition, including the impact of                             
IPv4 markets on likely future trajectories, but                                
really need some empirical data to parametrize our model.                      
with the help of many patient reviewers, we finally
have a draft ready for this list to chew on before 
we send out to larger ops mailing lists, e.g., nanog.

at the moment, we are not yet looking for people to 
fill out the survey, first we're looking for feedback on 
how to improve the phrasing of the questions so operators 
such as yourselves would find them easier to answer.
(because that will be my next appeal to this list..) 
keeping in mind that we are trying to parametrize a
quantitative model here, which drives the questions.

below i'll give an extremely terse description of the model
just to give you an idea of why we need this granularity.
there are another 10 pages describing the model pending 
peer review at NSF, which i can send to anyone interested in 
dedicating a few hours to giving us feedback on it.
but it's necessary for giving us feedback on the survey
questions, i think.

thanks much,
k, amogh, emile

------------------------------

Most prior work on modeling the adoption of new technologies assumed a
{\em binary decision} at the organization level -- in the context of
IPv6, this decision means switching completely to IPv6 or not at
all. We propose to account for the fact that an organization may
deploy IPv6 incrementally in its network, meaning that it will
continue to have both IPv4 and IPv6 space.  A key aspect of our model
is that instead of a binary state per organization, we work at the
granularity of {\em devices}, which are entities that need to be
assigned IP addresses. We consider a device to correspond to a single
instance of an IP addressing need, which typically corresponds to an
interface. Though there can be multiple interfaces (``devices'') on
the same computer/router, and multiple addresses (``virtual
interfaces'') on a single interface, we will model each need for an
independent IP address as an independent device.

At any point in time, a network has a set of devices numbered in
different ways. We define {\em device classes} based on the nature of
addresses used to number those devices.

\begin{enumerate}
\item {\bf V4-PURE} devices have only public IPv4 addresses.
\item {\bf V4-NAT} devices have only NAT IPv4 addresses.
\item {\bf V6-PURE} devices have only IPv6 addresses.
\item {\bf DS-NAT} devices are dual-stacked, with a NAT IPv4 address.
\item {\bf DS-PUB} devices are dual-stacked, with a public IPv4 address.
\end{enumerate}

In addition, the network uses some public IPv4 addresses to support
the NAT address space. We refer to the ratio of the number of private
IPv4 addresses to the number of public IPv4 addresses used to support
the NAT as the {\em overload factor} of the network. We model the {\em
network growth requirements} of each network in terms of the number of
additional devices in that network that need to be configured in one
of these device classes.

... (then we catalog a list of costs and incentives associated 
with the decision to adopt IPv6 or satisfy one's addressing 
needs with IPv4-based technologies. costs parameters include
as the costs of IPv4 addresses, NAT deployment, renumbering,
and translation between IPv4 and IPv6. we will also try to
model incentives such as policies and regulations.)

We will then model two separate decision processes for a
network, based on whether it seeks to add new devices (to
expand its network, provision for new customers, deploy new
services, etc.), or whether it seeks to optimize the numbering
of its existing devices from among the five device classes
defined previously. The latter operation may be necessary if
external factors and costs have changed such that the network
could substantially lower its costs by numbering its devices
differently. We want to structure the model (based on feedback
from opsfolk like you) to capture both initial costs as well
as ongoing operational costs of supporting a given configuration
of devices for a specified window following the decision.
Iteration of the decision process continues for each network
until we reach a state where no network has the incentive to change 
the numbering of its devices, which represents the equilibrium.
....