IPv6 survey from CAIDA

k claffy kc at caida.org
Sun Jan 22 00:38:08 CET 2012

might help if i included the survey URL:

On Sat, Jan 21, 2012 at 03:37:08PM -0800, k claffy wrote:
  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.
  \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.
  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.

More information about the ipv6-ops mailing list