[LACNIC/Politicas] [Fwd: [sig-policy] IPv6 Policy Proposal - prop-030-v001]
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Thu Aug 11 10:32:43 BRT 2005
Hola a todos,
Bajo mi punto de vista este punto requiere otra redaccion:
4. Amend the evaluation threshold calculation to be based on default end
site assignment size of a /56. Further end-site assignmentn
should be provided to APNIC in order to use a different average end-site
assignment size for HD-ratio calculation purposes
Tal y como esta ahora supone que el LIR tiene que justificar al RIR lo que
el usuario quiere, y eso implicara un proceso administrativo que al final
hara imposible la justificacion a los usuarios.
Imaginemos que un usuario utiliza todo el subneting que el /56 le permite.
Este usuario no debe de tener ninguna carga adicional, ni nigun sobreprecio,
y me atrevo a decir que ni siquiera necesitar renumeracion para pasar al
/48. De otro modo, tendremos NATv6 y no habra servido para nada la
transicion a IPv6.
Ademas, creo que esto es posible implementarlo. De que forma: Si los ISPs
reservan el /48 completo por si el usuario lo requiere, y se les asigna solo
la primera mitad, el usuario que lo requiera lo puede pedir y lo recibe, sin
mas. Tengamos en cuenta que el usuario que lo pida, es que realmente lo
requiere, nadie lo pedira por capricho, entre otras cosas porque el 99.9% de
los usuarios siquiera conocen esta posibilidad (no leen las politicas y aun
leyendolas no lo entenderian).
Con esto cumplimos el principio de "prevencion del agotamiento" que se
pretende con este cambio en la politica, si bien, las asignaciones siguen
haciendose a los LIRs.
Ahora bien, si relamente se llegaran a agotar las direcciones, y esto se
podria poner tal cual en la redaccion, se podria cambiar la politica de
forma que los LIRs empiezen a utilizar los /56 que han quedado reservados,
para aquellos usuarios que no los han pedido. Es decir, el LIR no tendria
que hacer una nueva peticion, puesto que dispondria posiblmente de casi el
99% del espacio que ha utilizado hasta ese momento.
Creo que es un balance bueno entre lo que se pretende con este cambio y lo
que se pretendia con el origen del RFC3177 y las politicas iniciales.
Que os parece ?
Espero vuestros comentarios un par de dias y lo redacto en Ingles y envio a
la lista global de discusion de politicas IPv6.
Regards,
Jordi
> De: Raul Echeberria <raul at lacnic.net>
> Responder a: <politicas-bounces at lacnic.net>
> Fecha: Thu, 11 Aug 2005 09:53:19 -0300
> Para: <politicas at lacnic.net>
> Asunto: [LACNIC/Politicas] [Fwd: [sig-policy] IPv6 Policy Proposal -
> prop-030-v001]
>
>
> Amigos:
>
> Paso esta propuesta que Geoff Huston ha hecho en la lista de políticas
> de APNIC para ser considerada en su próxima reunión.
> Me parece muy interesante porque va en la línea de algunas de las cosas
> que se discutieron en LACNIC VIII en Lima.
>
> Asumo que muchos estarán de acuerdo con estas ideas.
>
> ----------
>
> Dear friends:
>
> I am attaching the proposal that has been made by Geoff Huston in the
> APNIC Policy list, to be considered in the upcoming APNIC meeting.
> It seems to me very interesting, because it goes in the same direction
> that most of the comments made by the participants of LACNIC VIII on
> this topic.
>
> I guess that many of you will agree with these ideas.
> -------------
>
> Caros amigos:
>
> Envio esta proposta que Geoff Huston fez na lista de políticas de APNIC
> para ser considerada na sua próxima reunião.
> Acho muito interessante porque segue a mesma linha de algumas das coisas
> que se discutiram no LACNIC VIII em Lima.
> Acredito que muitos vão concordar com essas idéias.
>
>
> Raúl
>
>
> -------- Original Message --------
> Subject: [sig-policy] IPv6 Policy Proposal - prop-030-v001
> Date: Thu, 11 Aug 2005 11:26:26 +1000
> From: Geoff Huston <gih at apnic.net>
> To: sig-policy at lists.apnic.net
> CC: save at apnic.net, stephan at telstra.net
>
>
>
> Attached are text, pdf and word versions of a IPv6 policy proposal for
> consideration at APNIC-20
>
> regards,
>
> Geoff Huston
> Stephan Millet
>
>
>
>
> ______________________________________________________________
>
> prop-030-v001: Proposal to amend APNIC IPv6 assignment and utilisation
> requirement policy
>
> Authors: Stephan Millet <stephan (a) telstra.net>
> Geoff Huston <gih (a) apnic.net>
>
> Version: 1.0
>
> Date: 10 August 2005
> ______________________________________________________________
>
>
>
> Proposal to amend APNIC IPv6 assignment and utilisation requirement policy
>
> 10 August 2005
>
> Stephan Millet, Telstra
> Geoff Huston, APNIC
>
> ________________________________________
>
> Introduction
>
> The current APNIC IPv6 policies are documented in APNIC-089 „IPv6 Address
> Allocation and Assignment Policy‰. Under these policies, IPv6 end site
> assignment sizes are to be determined as follows:
>
> /48 in the general case, except for very large subscribers
> /64 when it is known that one and only one subnet is needed by
> design
> /128 when it is absolutely known that one and only one device is
> connecting.
>
> The current policy also specifies that address holders are able to receive
> a subsequent IPv6 allocation when they reach the „evaluation threshold‰.
> The evaluation threshold is a measure of past address utilization in terms
> of the number of end sites in /48 units and is determined using a HD-ratio
> of 0.8.
>
> This is a proposal to amend the end site assignment points with the
> addition of a further assignment size, amendment of the description of the
> applicability of the assignment sizes, the evaluation threshold value, and
> the method of calculating end-site assignment efficiency.
>
> These measures, if undertaken generally by all RIRs, would increase the
> anticipated useful lifetime of IPv6 to encompass a deployment period in
> excess of 100 years, in which period no further allocation or assignment
> policy changes are anticipated to the base addressing plan for IPv6.
>
> Summary of the current problem
>
> The current IPv6 policies were based upon the „wait and see‰ approach
> described in RFC 3177, under which only 15 percent of the available IPv6
> pool has been released for potential allocation, with the remaining 85
> percent „reserved‰ for allocation under potentially different allocation
> policies. The rationale of this approach was that if subsequent experience
> showed that the conditions of the initial addressing plan were flawed by
> being too liberal, then there would be opportunity to create more
> restrictive policies subsequently. However, such an approach also raises
> concerns relating to stability of the policy environment and questions of
> fairness in a system that may provide reward for early adopters and
> barriers for late adopters. This is a strong point of criticism in the
> refinement of IPv4 addressing plans, and, if possible, a recurrence of this
> situation with respect to IPv6 should be avoided.
>
> A detailed explanation of these issues is provided in Attachment A „The
> IPv6 Address Plan‰.
>
> Situation in other RIRs
>
> All RIRs currently uses the same policies relating to assignment sizes and
> evaluation threshold for IPv6. However, there have been discussions
> relevant to this proposal in the various RIR policy development forums, as
> described below.
>
> ARIN:
>
> During May 2005, the ARIN ppml mailing list received several postings from
> the community discussing issues similar to those raised in this policy
> proposal. In particular, on 25 May, a proposal to change the HD ratio in
> IPv6 allocations to 0.94 was submitted to the ppml mailing list. The policy
> proposal is still under discussion and is available at:
>
> http://www.arin.net/policy/proposals/2005_5.html
>
> LACNIC:
>
> At the LACNIC VIII meeting, there were discussions about the responsible
> allocating of IPv6 space. Many voices favoured retaining /48 as the default
> size for reassignment but to consider further observations about the use of
> a 0.8 HD-ratio. An evaluation of assignment sizes is to be carried out by
> the IPv6 Task Force Chair as a basis for further discussion at LACNIC IX.
>
> RIPE:
>
> During discussions at the RIPE 50 meeting, many expressed the view that /48
> assignments are too much for many users for now and in the future. There
> appeared to be general agreement that RFC3177 needs some revision. Although
> many people agreed that /48 assignments should remain, there was expression
> of a need for a new category that falls somewhere between /48 and /64, for
> users that have a need for subnetting but for which a /48 seems excessive.
> Discussions continued in the RIPE mailing list and it is expected that an
> Internet draft will be written in time for discussion at RIPE 51.
>
> AfriNIC:
>
> There have not been significant discussions on the AfriNIC mailing list
> relevant to this proposal.
>
> Details of proposal
>
> It is proposed to make the following changes to the existing APNIC IPv6
> policy:
>
> 1. Define an additional end site assignment size of /56. This /56
> assignment should be considered the „general case, intend for small
> office, household, and personal networks, and other small and medium-
> sized deployments where the number of potential subnets exceeds 1, but
> is not expected to exceed 256.
>
> 2. Amend the existing policy regarding /48 end-site assignments to refer
> specifically to assignments to large enterprise and corporate end-site
> environments where there is a requirement for more than 255 subnets at
> the end site.
>
> 3. Amend the IPv6 evaluation threshold for subsequent allocations to that
> matching an HD-ratio value of 0.94.
>
> 4. Amend the evaluation threshold calculation to be based on default end
> site assignment size of a /56. Further end-site assignment information
> should be provided to APNIC in order to use a different average end-site
> assignment size for HD-ratio calculation purposes.
>
> Advantages and disadvantages of adopting the proposed policy:
>
> The advantage of these proposed changes is that, on the basis of the best
> available evidence now, no significant changes would be required to the
> IPv6 assignment policies within the long term foreseeable future. This will
> also lead to greater degree of fairness in IPv6 use for the entire lifetime
> of the protocol.
>
> The potential disadvantage of these proposals is that the size of
> assignments to most end sites would be less generous. However, given the
> large amount space available within even a /56 prefix, this is unlikely to
> affect many users. In any event, larger sites will still be able to justify
> /48 assignments.
>
> For more details, please refer to Attachment A „The IPv6 Address Plan‰.
>
> Effect on APNIC members and general Internet community:
>
> End users:
>
> For sites falling with the classification listed within item 1 of the
> proposal, there is no significant impact, other than an increase in
> address efficiency through the assignment of an 8 bit subnet identifier
> space. It is not anticipated that such end sites will have a
> requirement for more than 256 distinct subnets.
>
> For larger sites, the /48 assignment size is preserved, and there is no
> impact arising from this policy proposal.
>
> ISPs and LIRs:
>
> ISPs and LIRs will have two changes to their use of IPv6 addresses.
>
> First, the threshold end site assignment efficiency level is between
> 30% to 50% for most ISPs and LIRs when based on a 0.94 HD Ratio. ISPs
> will need to undertake network address plans according to this target
> level.
>
> Secondly, end-sites will need to be classified within three general
> categories rather than the existing two: the /64 and /48 assignment
> sizes remain in place, but the /48 is now intended for larger corporate
> and campus end sites where the subnet requirement is anticipated to
> exceed 255 over time. Smaller end sites, including residential, SOHO,
> and medium office applications, where the subnet requirement is not
> anticipated to exceed 255 subnets are assigned a /56 as an end site
> assignment.
>
> Effect on NIRs:
>
> It is proposed that the NIRs would implement the amendments described
> above.
>
> Implementation
>
> Pending consensus to adopt this proposal in the Asia Pacific region, APNIC
> would liaise with the other RIRs in an attempt to achieve a globally
> coordinated consensus.
>
>
>
> Background Material
>
> The following material is not formally part of the Policy Proposal.
> It is included here only for informational purposes.
>
>
> 1. The IPv6 Address Plan
> Geoff Huston (Attachment A)
>
> 2. Internet Draft: draft-narten-iana-rir-ipv6-considerations-00.txt
> Thomas Narten
>
> 3. Internet Draft: draft-narten-ipv6-3177bis-48boundary-00.txt
> Thomas Narten
> Geoff Huston
> Lea Roberts
>
>
> ATTACHMENT A
> The IPv6 Address Plan
> July 2005
> Geoff Huston
>
>
> The IPv6 Global Unicast Address Plan uses a division of the address into
> three components: a global network identifier, that corresponds to an
> address prefix announced in the public network, a subnet identifier, which
> is used to support internal structure within corporate or campus networks,
> and a device identifier part that is used to support unique identification
> of hosts within the local subnet.
>
> The device identifier part of an IPv6 address is 64 bits in length, and the
> global identifier and local subnet identifier occupies the leading 64 bits.
> In addition, there are Internet Architecture Board guidelines that propose
> that the local subnet identifier should be generally fixed at a 16 bit
> length [RFC3177]. IPv6 global unicast addresses therefore have an
> associated address plan that uses a global network identifier in a 48 bit
> field, a subnet identifier in a 16 bit field, and a local device identifier
> in a 64 bit field (Figure 1).
>
>
>
> Figure 1 ˆ IPv6 Address Structure (RFC 3513, RFC 3177)
>
>
> It‚s reasonable to ask why the IPv6 address plan appears to have adopted
> the original IPv4 model of fixed length sub-fields within the address plan.
> The trade-off is one of simplicity versus efficiency. A fixed length
> address plan lends itself to simplicity in the associated procedural
> aspects of configuring a network and its devices with addresses. However,
> in adopting a Œone size fits all‚ approach, this fixed length address plan
> tends to err on the side of encompassing as many network scenarios as
> possible, and therefore allowing very generous sizes within the fixed size
> components of the address. Variable sized address plans tend to have higher
> procedural and operational overheads due the fact that every deployment is
> in effect a custom deployment, but can be adapted to meet individual
> requirements quite precisely. The IPv6 fixed length plan still allows
> customization, but the default action is the same in all cases, and, in
> theory, these networks can be rolled "out of the box."
>
> One of the objectives of IPv6 is to create networking environments that can
> work straight out of the box, and that setting up a network should not rely
> on detailed expert configuration of each network component. This is a
> natural outcome of the emerging concept of networking as a ubiquitous
> commodity. The rationale behind this design choice is that there is no
> effective shortage of address space, and therefore no reason to impose
> additional configuration burdens on the function of deployment of IPv6
> networks in the field. For this reason IPv6 has adopted the model of using
> both a fixed size parameter for the device identifier, defining this field
> as a 64 bit value, and recommending a general default size for the subnet
> identifier of a 16 bit field.
>
> Does this address architecture leave us enough address space to encompass
> all the various visions for deployment of IPv6?
>
> The Demand Model for Global Identifiers
>
> Within this address plan there are 48 bits for the global routing
> identifier. There are 281,474,976,710,656 global identifiers in this 48 bit
> space.
>
> The demand model for these global identifiers is effectively one of
> consideration of global populations over some decades to come. This
> includes considerations of numbers of households, numbers of workplaces,
> numbers of public agencies, in looking at human activities and their
> associated communications requirements. However we are also looking at
> aspects of deployment of silicon, which implies not only consideration of
> populations of conventional computers, but also consumer electronics, civil
> infrastructure elements, embedded devices and similar. The considerations
> of the size of these global populations is of the order of billions in each
> case, and in looking at a span of some five to tem decades of use this is
> perhaps better phrased as populations to be serviced with deployments of
> tens of billions in each of these segments.
>
> We can also expect that the massive scale of deployment will also lead to
> further commoditization of the service provider market, so that we may
> expect some thousands of service enterprises each servicing tens of
> millions of service endpoints in markets that will be characterized by
> economies of volume rather than higher valued efforts of service
> differentiation.
>
> The rough order of magnitude of the size of these end populations over time
> is one of the order of tens of billions, or even possibly low hundreds of
> billions. The demand population for addressed end sites is then of the
> order of 1011 to 1012. This is equivalent to 240, or some 40 bits of
> address space if we could achieve 100% address utilization efficiency in
> addressing end sites.
>
> The Routing Constraint
>
> Network addresses have utility when they are deployed in the context of a
> network. For the network to be able to use these addresses then the address
> plan must fit into the structure of available routing technologies.
>
> Making routing work across very large networks is a long standing issue,
> and our accumulated understanding of large scale routing to date is that
> the most effective scaling mechanism for routing is the use of aggregation
> of information through the imposition of hierarchies in the address plan.
> There have been a series of efforts to investigate future routing systems
> that exhibit radically different scaling properties as compared to the
> current capabilities of the Border Gateway Protocol, and it would be
> comforting to take the view that the global network will migrate to a
> different form of routing that has substantially improved scaling
> properties. However no such routing system has emerged so far from this
> work, and this different form of routing remains unspecified.
>
> It may be more prudent to take the view that the changes to the inter-
> domain routing system will be more incremental in nature over the coming
> years, and that the scaling properties of the existing inter-domain routing
> protocol, BGP, will be a continuing factor here. The current IPv4 network
> carries some 160,000 entries, or of the order of 105. It would be
> reasonable to expect that further refinements of the model and capability
> improvements in routing elements may lift this by some two orders of
> magnitude. This indicates that the constraint model of routing appears to
> be capable of supporting a system with the order of 107 entries.
>
> The difference between these two numbers, 1012 and107, requires some
> leverage in terms of aggregation of addresses into routing entries. The
> tool that we have to undertake this leverage is that of hierarchies in the
> address space, and the associated issue is that of the level of hierarchies
> that need to be used within various providers‚ address plans. The
> efficiency of such address plans in terms of the ratio of total address
> space and the numbered end sites is a critical factor in looking at total
> consumption levels.
>
> Aggregation and address hierarchies are, in general, relatively inefficient
> addressing plans, and in looking at total demand estimates then the
> expected address utilization efficiency is a factor in the overall demand
> estimation. It is also the case that the addressing plan has to accommodate
> both large and small providers.
>
> So the next question is one of aggregation efficiency, namely, what level
> of efficiency can be anticipated if one were to deploy 1012 end sites in a
> network routing system capable of supporting some 107routing entries?
>
> Current IPv6 Address Allocation Policies
>
> Before attempting to answer this question it is useful to briefly review
> the current address allocation policies as used for IPv6. The current
> structure is one where the Regional Internet Registries (RIRs) allocate
> address blocks to service providers. Within the terminology used by the
> RIRs these service providers are termed „Local Internet Registries‰ (LIRs).
>
> The minimum allocation unit to LIRs is a /32. LIRs can have access to
> larger address blocks based on a utilization target applied to the number
> of end sites for which they will be providing IPv6 services. This
> utilisation target is based on a Host Density Ratio (more later on this
> ratio).
>
> When the LIR has used the block in accordance with the target utilization
> level a further allocation is made, again with a minimum size of a /32
> address block.
>
> LIRs assign address space to end sites, or customers. The assignment
> policies note that where the end site is a single device with a single
> network interface, then the assignment is a single address, or a /128. If
> there is the certain knowledge that the end site will only have a
> requirement for a single subnet then the allocation is a /64. In all other
> cases the default assignment unit is a /48, allowing for a pool of 16 bits,
> or 65,536 values, to be used to number each subnet. Considering the range
> of possible subnet technologies that reach down to the level of personal
> networks such as Bluetooth, the anticipated general case is that each end
> site is assigned a /48 address block.
>
> The RIR address policies are based on a recommendation from the Internet
> Architecture Board, as documented in [RFC3177].
>
> The Host Density Ratio
>
> The above description uses the concept of a „target utilization level‰ as a
> means of determining when a block of addresses is considered to be fully
> utilized.
>
> Networks are not static entities, and various parts of a network grow and
> shrink over time. The common practice is to divide a network's address
> space into continuous blocks of addresses, each of which is assigned to
> serve a distinct section of the network, or subnet. When a new device is
> added to a part of the network the intent is that the new device is
> assigned an available address from the local subnet address pool, leaving
> the addressing of the remainder of the network unaltered. When the subnet
> address pool is exhausted then it is necessary to renumber the subnet into
> a larger address pool. Renumbering a network or even a subnet is at best an
> extensive and highly disruptive operation. For large networks it becomes a
> protracted and expensive affair that is best avoided.
>
> For this reason a common network address plan attempts to provide each
> subnet with sufficient address space to number not only the current
> collection of attached devices, but also to encompass future expansion of
> the subnet over time. This implies that achieving a 100% use level of
> addresses is not an achievable objective. What level of utilization is
> achievable?
>
> Early experience with this in the IPv4 world indicated that achieving an
> address utilization rate of 10%, where 10% of the address block was
> actually used to number devices and 90% was sitting unused in various
> address pools was an reasonable outcome. Subsequent refinements of the
> subnetting model in IPv4 with variable length subnet address blocks allowed
> far higher utilization rates to be achieved, and current IPv4 address
> distribution policies call for address utilization rates of some 80% as a
> threshold level that should be achieved before more address space is
> allocated to the service provider.
>
> This is a relatively extreme metric, and it places a considerable burden on
> local network managers to achieve such a high address utilization level. It
> is often the case in IPv4 deployments that local managers use private
> addresses using a much lower address utilization level and then place
> network address translators on the boundary in order to meet these
> objectives. It is certainly an stated objective of IPv6 to eliminate the
> forced need to deploy these forms of on-the-fly packet translators in a
> network and some thought has gone into devising a more suitable address
> utilization metric.
>
> With IPv6 the concept of address utilization efficiencies has been
> redrafted. Within end-sites each subnet has 64 bits of address pool, and no
> particular utilization target is specified. Even in terms of numbering of
> subnets there is no particular address efficiency metric, as each end site
> is assigned a 16 bit subnet space that they can deploy in any manner of
> their choosing. The only place where an efficiency metric is specified is
> with the ISP, and that is a metric of the efficiency of the end-site
> numbering within the service provider‚s address pool. In other words we are
> talking about the efficiency metric of /48 assignments, and not of end
> device /128 address assignments. An additional consideration has been that
> a fixed threshold value of a /48 utilization metric irrespective of network
> size either imposes an unnecessary burden on larger service providers if
> high threshold values are used, or is highly inefficient for smaller
> service providers if small threshold values are used, and an alternative
> form of calculating a varying efficiency metric has been used.
>
> The guiding observation in defining this calculated efficiency metric is
> that a service provider network typically use a number of levels of
> hierarchy. A large service provider may divide the address pool into
> regional address blocks. Within each region the address block is likely to
> be further divided into address blocks per network access point, or POPs.
> Within each POP each address block may be further divided into access
> classes. Within each access class address block individual end-site
> addresses are assigned. This then defines a four level internal address
> hierarchy. This plan is intended to ensure that there is some
> aggregateability in the address prefixes carried in the network‚s interior
> routing system, so that the routing system can operate in a scaleable and
> stable fashion. In such larger IP networks there may be of the order of
> millions of end site address assignments, and possibly much larger in a
> IPv6 commodity world, and address aggregation is the only way to reduce the
> internal routing load to a more viable size of the order of thousands of
> routed prefixes at any point in the network, rather than millions. Smaller
> networks may have a smaller number of internal levels of hierarchy, perhaps
> using only one or two levels. Networks with greater levels of network
> structure, and corresponding greater levels of address aggregation
> hierarchy, have less efficient utilization efficiencies than those with
> smaller levels of network structure, and smaller levels of address
> aggregation hierarchy. Assuming that at any level of the hierarchy a
> utilization efficiency of, say 0.7 (or 70%) can be achieved, then a two
> level hierarchy achieves a threshold level of efficiency of 0.49 (or 0.72)
> and a four level hierarchy would map to an efficiency value of 0.24 (or
> 0.74).
>
> The next part of this process is to define the relative sizes of „large‰
> and „small‰ networks in terms of the change in network size that
> corresponds to the addition of a new level of internal hierarchy.
> Experience to date indicates that this relationship between network size
> and levels of internal network structure is not a linear relationship, but
> looks more along the lines of some form of multiplicative increase in size
> for each additional level of structure. For example, the relationship may
> correspond to an increase in size of the network by a factor of, say, 4,
> for each additional level of network structure. This leads to the general
> observation that we are looking at a relationship of two exponential
> values, in which case the ratio of the log of these two values is a
> constant.
>
> And this leads to the Host Density Ratio. This ratio is expressed as:
>
> HD = log(number of allocated objects) / log (pool size)
>
> The value used in the IPv6 address allocation policies is an HD Ratio of
> 0.8.
>
> The following table shows the target utilization levels for various sizes
> of IPv6 address blocks, where the right-most column is the threshold level
> of utilization according to the 0.8 HD-Ratio value.
>
>
> Prefix /48 count end-site count
>
> /32 65,536 7,132
> /31 131,072 12,417
> /30 262,144 21,619
> /29 524,288 37,641
> /28 1,048,576 65,536
> /27 2,097,152 114,105
> /26 4,194,304 198,668
> /25 8,388,608 345,901
> /24 16,777,216 602,249
> /23 33,554,432 1,048,576
> /22 67,108,864 1,825,677
> /21 134,217,728 3,178,688
> /20 268,435,456 5,534,417
> /19 536,870,912 9,635,980
> /18 1,073,741,824 16,777,216
>
> Table 1 (A) ˆ Application of the 0.8 HD Ratio
>
> Putting it all together
>
> The IPv6 address plan is intentionally one that is simple and easy to use.
> The IPv6 address plan is intended to provide simple structures that allow
> low overhead deployments of small and large networks, both for the local
> network management or end site and for the IPv6 service provider in
> deploying an address plan across their network with ease of expansion while
> avoiding renumbering whenever possible. The IPv6 address plan is also
> intended to accommodate the consideration that aggregation and hierarchies
> of address structures are not highly efficient users of address space.
>
> The inputs to the total consumption of address space are the factors of a
> 64 bit device identifier, a 16 bit subnet identifier, an HD-Ratio of 0.8
> for end-site utilization, a set of global populations of network
> deployments and an anticipated lifetime of at least 60 years. The basic sum
> is an end-site population of between 50 billion and 200 billion. Applying
> at HD-Ratio of 0.8 to this range of values gives a total address
> requirement of between a /1 to a /4. That‚s between 1/2 and 1/16 of the
> total IPv6 address pool.
>
> The corresponding 0.8 HD Ratio mapping is indicated in the following table:
>
>
> Prefix /48 count end-site count
>
> /17 2,147,483,648 29,210,830
> /16 4,294,967,296 50,859,008
> /15 8,589,934,592 88,550,677
> /14 17,179,869,184 154,175,683
> /13 34,359,738,368 268,435,456
> /12 68,719,476,736 467,373,275
> /11 137,438,953,472 813,744,135
> /10 274,877,906,944 1,416,810,831
> /9 549,755,813,888 2,466,810,934
> /8 1,099,511,627,776 4,294,967,296
> /7 2,199,023,255,552 7,477,972,398
> /6 4,398,046,511,104 13,019,906,166
> /5 8,796,093,022,208 22,668,973,294
> /4 17,592,186,044,416 39,468,974,941
> /3 35,184,372,088,832 68,719,476,736
> /2 70,368,744,177,664 119,647,558,364
> /1 140,737,488,355,328 208,318,498,661
>
> Table 1 (B) ˆ Application of the 0.8 HD Ratio
>
> Using this HD ratio across the total IPv6 address pool, the address pool
> has a total capacity of numbering 0.0013 x 248 end sites, or
> 362,703,572,709, roughly some 362 billion addressed end sites. By
> comparison a similar estimate is provided in RFC3177, which provided a
> total end-site census of some 178 billion end-sites, and a calculation of
> an equivalent address requirement of a /3.
>
> Considering that this calculation of total demand for IPv6 end site
> addresses makes a number of quite sweeping assumptions there is some
> uncertainty associated with this estimated total of between 50 to 200
> billion end sites. We may need to stick with this technology for longer
> than 60 years. It may be that our assumptions about the ubiquity of silicon
> devices are inadequate, or that we may see the use of different address
> models, such as one-off use of addresses. These factors can be summarized
> as:
> Time period estimates (decades vs. centuries)
> Consumption models (recyclable vs. one-time manufacture)
> Network models (single domain vs. overlays)
> Network Service models (value-add-service vs. commodity
> distribution)
> Device service models (discrete devices vs. ubiquitous embedding)
> Population counts (human populations vs. device populations)
> Address Distribution models (cohesive uniform policies vs. diverse
> supply streams)
> Overall utilization efficiency models (aggregated commodity supply
> chains vs. specialized markets)
>
> The question that arises from this is: are we comfortable with this outcome
> given these uncertainties over the total demand estimate? Is IPv6 truly big
> enough?
>
> If not then we need to consider the various components of the IPv6 address
> plan and see if there are some parameter adjustments that can be made that
> would allow some greater margins in the total address consumption levels.
> The three areas of consideration are :
>
> 1. the size of the interface identifier (currently set to 64 bits),
>
> 2. the size of the subnet identifier (currently set to 16 bits), and
>
> 3. the value of the Host Density Ratio (currently set to 0.8).
>
> Let‚s look at each of these in turn to see if there is some latitude to
> change these settings in such a way that would provide some greater level
> of „comfort margin‰ for ensuring that the total IPv6 address consumption
> value can readily fit within the IPv6 address plan.
>
> 1. The 64 bit Interface Identifier
>
> The IPv6 address plan divides the address into two distinct parts: a
> network location identification part and a device interface identification
> part. The dividing point is at the 64th bit position.
>
> It was anticipated that this would allow each manufactured network media
> interface to be assigned a unique 64 bit identification code. This
> interface identification code was intended to function in some fashion as
> an endpoint identification, where, irrespective of the location of the
> endpoint within the network, it would maintain its unique endpoint
> identification. The implication here is that the same endpoint identity
> values cannot be used by two or more distinct endpoints. This turns the
> capacity of the address space into 264 possible endpoints in any one of 264
> network locations. The benefit was an intention to provide a solution to
> the current semantic overloading of an IPv4 address, which encompasses
> elements of both location and identity. However, there are a number of
> unresolved issues here, relating to uniqueness, persistence, authenticity
> and privacy of this identity space.
>
> The 64-bit IPv6 interface ID is an architectural boundary in IPv6, defined
> by Stateless Address Autoconfiguration [RFC2462]. This function assumes
> IPv6 interface identifiers are fixed length 64 bit fields. Changing this
> boundary would impact existing implementations of this function, and any
> transition to a different boundary would take some time. An alternative
> approach is to deprecate stateless autoconfiguration completely for
> generating interface identifiers and use the Dynamic Host Configuration
> Protocol (DHCP) for this function. However, client implementation of DHCP
> for address configuration are not mandatory in IPv6, and it is believed
> that a significant percentage of IPv6 implementations do not support DHC
> for address configuration.
>
> So already it appears that even prior to mass deployment IPv6 has managed
> to accumulate some issues of legacy here, and while a change in the length
> of this identifier would recover a large number of address bits, this would
> have some impact on existing implementations of IPv6.
>
> There is a considerable measure of reluctance for further protocol change
> here that must be acknowledged. IPv6 has had a considerable developmental
> lead time and there is a substantial body of opinion that it is time to
> cease further protocol specification modifications and provide industry
> with a stable view of the IPv6 protocol. Without this assurance of
> stability vendors are reluctant to commit the protocol into products,
> service providers are reluctant to commit to deployment programs and the
> protocol remains an experiment rather than a service platform for a
> communications network. So while this particular part of the address plan
> represents the greatest level of gain in terms of total address capacity,
> it also presents a considerable risk to the industry acceptance of IPv6,
> and for this reason changes in the length and structure of this part of the
> IPv6 address plan do not represent a preferred path.
>
> 2. The Subnet Identifier
>
> The subnet identifier part of the IPv6 address is a variable length field.
> However, within the parameters of current address allocation policies the
> Regional Internet Registries assume that general case for end site
> assignments are /48s, and thus utilization measurements are based on an HD-
> ratio that counts numbers of /48 assignments. Allocating a /48 to an end
> site allows each site to deploy up to 65,536 subnets. While that number may
> make sense for larger enterprises, it is admittedly hard to imagine a
> typical home network, or a personal local area network requiring this much
> subnet address space.
>
> Looking back at some of the original motivations behind the /48
> recommendation [RFC3177], one overriding concern was to ensure that end
> sites could easily obtain sufficient address space without having to "jump
> through administrative hoops" to do so. As a comparison point, in IPv4
> typical home users are given a single public IP address (even this is not
> always assured), but getting even a small number of additional addresses is
> often a more expensive option either in terms of the effort needed to
> obtain additional addresses, or in the actual cost involved. It should be
> noted that the "cost" of additional addresses cannot generally be justified
> by the actual supply cost of those addresses, but the need for additional
> addresses is sometimes used to imply a different type or "higher grade" of
> service, for which some ISPs charge a premium. Thus, an important goal in
> IPv6 was to significantly change the default end site assignment, from "a
> single address" to "multiple networks".
>
> Another motivating concern was that if a site changes ISPs and subsequently
> renumbers, renumbering from a larger set of "subnet bits" into a smaller
> set is particularly painful, as it can require making changes to the
> network itself (e.g., collapsing links) as well as reconfiguring the
> network into a different prefix and associated prefix length. In contrast,
> renumbering a site into a subnet that has the same number of subnet bits is
> considered to be easier, because only the top-level bits of the common
> address prefix need to change. Thus, another goal of the RFC 3177
> recommendation is to ensure that upon renumbering, one does not have to
> deal with a comprehensive reconfiguration of the local network.
>
> These concerns were met by the /48 recommendation, but could also be
> realized through a more conservative approach. For example, one can imagine
> "classes" of users, with default sizes for each class. For example:
>
> - A PDA device with a low bandwidth WAN connection and a personal area
> network (PAN) connection - a single network or /64 assignment.
>
> The /64 assignment allows for the addressing of a number of hosts, each
> connected to the same PAN link as the device. This would be appropriate
> in deployments where the end device is not expected to provide
> connectivity services to a larger site, but is intended to provide
> connectivity for the device and a small number additional devices
> directly connected to the same PAN as the primary device.
>
> - Small Office, Home Office (SOHO) - expected to have a small number of
> networks - a /56 assignment
>
> This is similar to the /48 motivation, but includes the expectation
> that the typical small office or home environment has a limited
> requirement for multiple discrete subnets, and this expectation could
> be generally achieved within a pool for 256 discrete subnet
> identifiers.
>
> - Other enterprise and organizational entities ˆ a /48 assignment as the
> default
>
> Although, as with existing allocation policies larger end site
> allocations are possible within this framework , according to the total
> end site requirement.
>
> A change in policy (such as above) would have a significant impact on
> address consumption projections and the expected longevity for IPv6. For
> example, changing the default allocation from a /48 to /56 (for the overall
> majority of end sites) would result in a reduction of cumulative address
> consumption by some 6 or 7 bits, or around two orders of magnitude. Of
> course, the exact amount of change depends on the relative number of home
> users compared with the number of larger sites over time.
>
> One can, of course, imagine a policy supporting the entire range of
> assignments between /48 and /64, depending on the size or type of each end
> site. However, this must be balanced against the advantages of having a
> small number of simple policies, so that end users can easily identify
> which assignment size is appropriate for them, and that there is wide
> agreement among ISPs as to what reasonable assignment sizes are for a given
> customer class. Having excess flexibility in selecting an appropriate
> assignment size for a given customer type can lead to different ISPs
> offering different assignment sizes to the same customer. This is
> undesirable because it may lead to a need to renumber into a smaller subnet
> space when switching ISPs, or may lead to ISPs attempting to differentiate
> their service offerings by offering the most liberal address assignment
> policies, defeating the purpose of having a wide range of policies.
>
> The advantage of this approach is that it does not impact on existing IPv6
> protocol implementations, nor does it create a legacy or transitional
> impact. This sits comfortably within the realm of a change to the
> allocation policy parameters that allow a more precise fit of the size of
> the allocated address block to the nature of the intended use of the
> addresses without imposing a significant additional administrative overhead
> on service providers, vendors or end consumers.
>
> 3. The HD Ratio
>
> Coming from an IPv4 deployment environment the HD-Ratio value of 0.8
> represents a relatively radical change to the way in which we view end
> sites address allocations. For example, under the IPv4 address allocation
> policies a consumer market service provider with some 5 million customers
> would be expected to achieve an overall 80% address utilization. This would
> correspond to an address plan that would service this customer base from a
> pool of some 6.5 million /32 IPv4 addresses, or a total address allocation
> of a /9. A further allocation would be made only when the total addressed
> population exceeds 6.5 million. These days with DHCP and NATS most service
> providers have become accustomed to achieving even higher address
> utilization densities in IPv4, and it is not unusual to see such a service
> provider with some 5 million customers using a total address pool of a /11,
> or some 2 million /32 addresses.
>
> The equivalent allocation in IPv6 would be a /20, or some 268 million /48
> end site prefixes to service the same 5 million customers. And once the
> customer population exceeded some 5.5 million customers the allocation
> policies would allow for a further application of a /20, making a total of
> some 536 million end site addresses to draw from. This 1% utilization level
> of end sites addresses is well distanced from the current IPv4 allocation
> parameters, and the question arises as to whether this allocation policy
> has managed to pass across the points of sound engineering and venture into
> the spaces that could be associated with extravagant use.
>
> As noted above the basic proposition behind the HD Ratio is that the number
> of internal levels of aggregation hierarchy within a network increases in
> proportion to the log of the size of the network, and that at each level in
> the hierarchy one can expect to achieve a fixed level of utilization
> efficiency. This basic proposition appears to match our understanding to
> the capabilities of routing and also appears to match out experience with
> network design, so there appears to be nothing intrinsically wrong with the
> capability of the HD Ratio to capture the nature of address use within
> deployed networks.
>
> However, the lingering uncertainty remains that the value of 0.8 may not be
> the most appropriate value to capture what we would regard as reasonable
> engineering practice in network design, particularly with larger networks.
> In exploring scenarios that would result from various HD Ratio values, the
> first step is to look at the efficiency outcomes that would result from
> differing values of the HD Ratio, and map these back to the basic function
> of the number of internal levels of network hierarchy. Figure 2 shows the
> various utilization efficiency values that result from changing the HD
> Ratio for various sizes of address blocks.
>
>
>
> Figure 2 ˆ HD Ratio Outcomes
>
>
> The first vertical line represents the minimum allocation size of a /32.
> With a HD Ratio value of 0.8 a service provider can obtain a further
> allocation of address space once the utilization efficiency reaches 10%, or
> some 6,500 end sites drawn from a pool of 65,536 site identifiers. The
> second vertical line represents our example service provider with its 5
> million customers. With an HD Ratio of 0.8 the threshold utilization
> efficiency level is some 2%. In terms of internal levels of network
> hierarchy this corresponds to 18 internal levels of hierarchy at a per-
> level efficiency of some 80%. Even with a per-level efficiency level of 70%
> this still represents 11 levels of internal hierarchy within the network.
>
> This 0.8 value for the HD Ratio does not appear to capture reasonable
> engineering expectations of network design. Even the largest service
> provider networks do not encompass more than 5 or 6 levels of internal
> hierarchy and the internal routing protocols typically operate on a simple
> two level hierarchy.
>
> It may be useful to consider a higher value of the HD Ratio for address
> allocation policies. As can be seen in Figure 2, an HD Ratio value of 0.94
> would rephrase these threshold levels such that a /32 would need to be used
> at a level of some 50% before a further allocation is made, while the /20
> allocation would need to achieve a 31% efficiency level. This latter value
> represents a network with 5 internal levels of hierarchy, each being
> utilized to an average of 80% efficiency. As an initial observation this
> latter value appears to represent a more realistic model of network
> deployment based on a competently executed network design.
>
> Another way of looking at this data is to examine the recent past in terms
> of Internet business activity levels in IPv4, as expressed in address
> allocations, and see how this would relate to IPv6. The basic question
> posed in this exercise is: what would‚ve been the total address consumption
> level over the past three years if we had been using IPv6 instead of IPv4?
> And how would this total consumption profile change if we‚d been using a
> different value for the HD Ratio?
>
> This simulation exercise produces some surprising outcomes. The first is
> that 80% of the address allocations would remain at the /32 minimum
> allocation size or at a /31. Varying the HD Ratio between 0.80 and 0.96 has
> little impact on this outcome. So for the majority of ISP‚s in the last
> three years a change in the HD Ratio value would have no significant impact
> on the amount of allocated addresses that they would receive. The second
> outcome is that only 2% of allocations are greater than a /27. Changing the
> HD Ratio for these allocations would lift the average address utilization
> efficiency level from 4% to 25% by a change in the HD Ratio value from 0.80
> to 0.94. In other words only a small number of large providers would see
> some change in the target efficiency levels with such a change. The third
> outcome is that the change in total address consumption by such a change in
> the HD Ratio value is a factor of 10. In other words under the current HD
> Ratio value of 0.8 a small fraction of the allocations (2%) is consuming
> over 95% of the total address pool.
>
> So perhaps there is some benefit in reviewing this initial choice of 0.80
> as an HD Ratio value. The relevant questions here is what is an appropriate
> HD Ratio value to use? Certainly the initial choice of 0.8 as a value was a
> somewhat arbitrary one, made more in an effort to define an initial set of
> address allocation policies than being based in a more deeply researched
> effort to model sound engineering design principles. In reconsidering this
> value it would be helpful to consider the following aspects:
>
> - What is common practice in today‚s network in terms of internal
> architecture?
>
> - Should we define a common Œbaseline‚ efficiency level rather than an
> average attainable level? In other words, what value would be readily
> achievable by large and small networks without resorting to frequent
> network renumbering or unacceptable internal route fragmentation?
>
> - What are the overall longer term objectives? What is the anticipated
> address pool lifetime of various HD Ratio values? What would be the
> anticipated impact on the routing space?
>
> It would appear that some further activity is needed here to explore what
> value for a threshold address utilization efficiency level represents a
> reasonable balance between simplicity of network deployment and the larger
> issues of conservatism in the impacts on the routing space and ensuring
> that the overall address pool can indeed accommodate extended lifetime
> expectations.
>
> Putting it back together again
>
> It appears that there are two aspects to the current address policy
> framework that merit further broad consideration, namely the subnet
> identifier size and the HD Ratio.
>
> An additional point in the subnet allocation policy, using a /56 allocation
> point for SOHO End Sites in addition to the current /48 End Site allocation
> point may alter the cumulative address consumption total by some 6 to 7
> bits of address space, without any major impact on the engineering of end
> site networks, and without any significant impact on service provider
> procedures in address allocations to end sites. Such a measure would still
> preserve the essential elements of simplicity while allowing the overall
> majority of end sites to use an address block that is more commensurate
> with anticipated needs in terms of subnetting.
>
> The HD Ratio appears to be another area of further study. Initial studies
> of the impacts of various HD Ratio settings indicate that if the HD Ratio
> setting of 0.8 implies a total consumption of a certain amount of address
> space, then a setting of 0.87 would imply a total consumption of ∏ of this
> amount and a setting of 0.94 would imply a total consumption of 1/10 of
> this amount. In other words there is the potential to alter the cumulative
> consumption of address space by some 3 bits.
>
> Just these two measures would provide latitude to reduce total consumption
> levels by up to 10 bits, or a total consumption of between a /10 to a /17
> of address space. If the initial estimates of a total consumption of a /1
> to a /4 appear to represent some level of discomfort in the total capacity
> of IPv6 it is reasonable to estimate that a /10 to a /17 would represent a
> much higher level of confidence that IPv6 would be capable of meeting a
> much broader set of potential future scenarios for the role on the Internet
> across the coming century or perhaps even longer.
>
> The total capacity of the IPv6 address plan would be then encompass 0.1 x
> 252, or 450,359,972,737,050 addressed end sites. That‚s 450 thousand
> billion, a one thousand-fold increase in total capacity. Even given the
> considerable levels of uncertainty over our original total demand estimate
> of between 50 to 200 billion end sites, this revised outcome appears to be
> a very comfortable fit.
>
> Public Policy and the „Fairness‰ factor
>
> If the current IPv6 address plan has some risks of premature exhaustion. It
> is possible to make some adjustments to this address plan without any
> related protocol changes. Such adjustments would be capable of mitigating
> these risks. The consequent question is whether these adjustments should be
> undertaken now or later.
>
> One approach is to adopt a „wait and see‰ attitude, and defer consideration
> until more data is available. This viewpoint is expressed in RFC3177:
>
> We are highly confident in the validity of this analysis, based on
> experience with IPv4 and several other address spaces, and on
> extremely ambitious scaling goals for the Internet amounting to an
> 80 bit address space *per person*. Even so, being acutely aware of
> the history of under-estimating demand, the IETF has reserved more
> than 85% of the address space (i.e., the bulk of the space not
> under the 001 Global Unicast Address prefix). Therefore, if the
> analysis does one day turn out to be wrong, our successors will
> still have the option of imposing much more restrictive allocation
> policies on the remaining 85%. However, we must stress that vendors
> should not encode any of the boundaries discussed here either in
> software nor hardware. Under that assumption, should we ever have
> to use the remaining 85% of the address space, such a migration may
> not be devoid of pain, but it should be far less disruptive than
> deployment of a new version of IP.
> [RFC3177]
>
> An alternative way of expressing this perspective is that it appears to be
> premature to consider changes to the IPv6 address plan when we have so
> little experience with deployment of IPv6. It would appear that we are not
> qualified to make such decisions and we should defer the entire matter to
> more qualified individuals. Who would they be? From this perspective they
> would be the network engineers of the future who would have had 10-20 years
> of IPv6 operational experience.
>
> Lets look at this assertion in a little more detail. If the consumption
> analysis in RFC3177 is indeed flawed, and uptake is larger than has been
> anticipated, then yes, there will still be large pools of unallocated
> address space available, and yes, it will be possible, in theory at any
> rate, to use a different addressing plan on this remaining space which
> targets a higher utilization rate. However the installed base of IPv6 will
> also be extremely large at this point. Indeed the deployed base will be so
> large that the problem of inertial mass and potential inequities in
> distribution structures will effectively imply that any changes will be
> extremely tough, if feasible at all.
>
> It could be argued that we have already lived through a similar transition
> in IPv4 in the change from class-based addressing to one of classless
> addressing plus Network Address Translators. The legacy of this transition
> is uncomfortable, with later adopters pointing to the somewhat liberal
> address holdings of the early adopters and asking why they have to bear the
> brunt of the cost and effort to achieve very high address utilization rates
> while the early adopters are still able to deploy relatively simple, but
> somewhat more extravagant addressing schemes across their networks.
>
> When to consider such a change to the address plan is very much a public
> policy topic. While there is a temptation to leave well alone, from a
> public policy perspective we stand the risk of, yet again, visibly creating
> an early adopter reward and a corresponding late adopter set of barriers
> and penalties. I suspect that IP has already exhausted any tolerance that
> may have been enjoyed in the past on this type of behaviour and there is a
> strong impetus on the part of many developing populous economies not to see
> such a precise rerun of what they would term previous mistakes. This is not
> an abstract concept but one where we are already seeing proposals from the
> ITU-T to establish an alternative IPv6 address distribution system that
> appears to be based around this particular concern that by deferring this
> decision once more we appear to be creating a framework that establishes
> early adopter rewards and late adopter penalties.
>
> In other words it is possible to put forward the case that considering
> changes to the IPv6 address plan at this point is a premature discussion,
> but others, for equally valid reasons, see it as being timely, while others
> see this as an urgent priority. There is a case to be made that we should
> study the evolution of address policies in the history of IPv4 and be
> careful to avoid a needless repetition of earlier mistakes. It would appear
> to be prudent, and indeed „fairer‰ to plan for success rather than failure,
> and plan for extensive, indeed ubiquitous deployment of IPv6 for an
> extended period of time. In such a scenario there is little room for
> structural inequities in the address distribution model, and that at all
> times all players should be positioned evenly with respect to access to
> addresses. Consequently there would be little room to adjust the address
> plan parameters on the fly and we should exercise some care to ensure that
> the address plan structure we adopt at the outset has sufficient room to
> accommodate future requirements on a similar, if not identical, basis. From
> this perspective the time for consideration of the address plan and its
> associated parameters is now, rather than deferring the matter to some
> unspecified future time.
>
> The alternative is that the installed base of IPv6 will consume very little
> address space in the coming decades, in which case the entire topic would
> be irrelevant! In other words this topic is predicated on the assumption
> that in some 50 or 100 years hence we will still be using IP as the base
> technology for a global communications enterprise.
>
> This is a central topic to the entire consideration of IPv6 address plans.
> My best answer to this assumption is that I really don't know which,
> logically, admits the possibility of "yes, we‚ll still be using IP a
> century hence.‰ Some technologies are "sticky" simply because they work and
> the cost of universal adoption of alternatives is just too high. Over a
> century later we still use the internal consumption engine, many decades
> later we still use amplitude modulated radio signalling, and so on. It may
> well be the case that packet switching and IP is one of these „sticky‰
> technologies, in which case the longevity of the address architecture is
> indeed a critical issue.
>
> Its not clear that we should be in the business of built in obsolescence,
> and certainly not if we can buy additional time without undue pain. We‚ve
> looked at the HD ratio and the subnet boundary as potential points of
> variation in the IPv6 address plan that could admit more efficient
> utilization without substantial alteration to the overall IPv6 architecture
> and without undue need to alter existing equipment, software or current
> deployments, such as they are today. Its certainly the case that alteration
> of the length of the global identifier could admit vastly greater address
> utilization benefits but of course the question here is, simply, whether
> the gain is worth the pain.
>
> However, its sensible to also note that if we think that "installed base"
> is an argument today in terms of the pain associated with changing the 64
> bit length for the device identifier, just wait until the installed base of
> end sites gets to the 30 billion mark that is commensurate with a /4
> consumption under current policies. 30 billion end sites would be a very
> impressively large installed base, and its inertial impetus would say to me
> that at that stage your wriggle room for changes in the address plan for
> the remaining space is pretty much a lost opportunity. So if we are having
> trouble now in looking at the global identifier on the basis of the
> inertial mass of already deployed systems and services, then you cannot
> also put forward the proposition that we can change things once we've
> deployed 30 billion end site instances of the same.
>
> So I'm afraid that "we've still got adjustment room in the future so don't
> worry about it now" is not an approach that can be accepted easily - if at
> all. At that point the late comers will be complaining that they are
> exposed to tougher and more constrained policies that are deployed at a
> higher cost than that of the early adopters - and if all this sounds
> hauntingly familiar in reference to the current debates about national
> interests and highly populous economies and various address policy
> frameworks, then it should. I'm afraid that there's an increasing cynicism
> out there about the refrain of "don't worry we'll fix it once its visibly
> broken" with respect to address policies. We should at this point be
> striving to instil some broad confidence in the proposition that we can
> provide a stable and enduring platform for the world's communications
> needs.
>
> While the HD-Ratio setting and the end-site prefix assignment points are
> simply adjustments to the address plan and do not impact the protocol
> architecture, the 64/64 split is not quite in the same category here. There
> is an impact on the current address architecture and indeed on the protocol
> specification itself. Its true that the original motivations for this
> particular aspect of the address architecture have largely dissipated, or
> at least have been unable to be realized, and the residual reasons for its
> adoption are based more in legacy conformance than in true utility. But
> here its not quite so clear to me that change is necessary . Maybe it would
> be more practical to pursue some more conservative opportunities that
> represent some small scale parameter value shifts and adopt a preference to
> look at the HD Ratio and the End Site identifier allocation size points
> over looking at the 64 bit split point between local identification and
> routing identifiers.
>
> In attempting to look at measures that would ensure a prolific and valuable
> lifecycle for IPv6 over an extended time care needs to be exercised in
> ensuring that we continue to have a stable technology base in IPv6. Further
> changes to the IPv6 protocol at this stage would entrench attitudes that
> IPv6 remains a developmental exercise rather than a technology capable of
> sustaining a global investment of trillions of dollars over the coming
> decades. However, happily, there does appear to be sufficient scope to make
> some small parameter changes to the IPv6 address allocations policies
> without making any changes to the protocol itself that would ensure that
> even the most optimistic predictions of uptake of IPv6 across its lifetime
> can be readily fuelled by availability of that most essential element of
> networks: addresses.
>
> References
>
> RFC 1715 The H Ratio for Address Assignment Efficiency, C. Huitema,
> November 1994.
>
> RFC 2462 IPv6 Stateless Address Autoconfiguration, S. Thomson, T.
> Narten, December 1998.
>
> RFC 3177 IAB/IESG Recommendations on IPv6 Address Allocations to
> Sites, IAB, IESG, September 2001.
>
> RFC 3194 The H-Density Ratio for Address Assignment Efficiency. An
> Update on the H Ratio, A. Durand, C. Huitema, November
> 2001.
>
> RFC 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture,
> R. Hinden, S. Deering, April 2003.
>
>
> * sig-policy: APNIC SIG on resource management policy
> *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> http://www.lacnic.net/mailman/listinfo/politicas
************************************
The IPv6 Portal: http://www.ipv6tf.org
Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
More information about the Politicas
mailing list