[afripv6-discuss] Fwd: potpourri

[Adiel A. Akplogan]

This is an interesting statement in regard of ongoing discussions in
many RIRs policy forum about the actual IPv6 allocation policy.

- a.

>From: "Tony Hain" <alh-ietf at tndh.net>
>To: <ipv6 at ietf.org>
>Date: Wed, 3 Aug 2005 14:28:52 +0200
>
>Following up on the meeting session:
>
>As the IPv6 working group draws to a close the *only* proper action is to
>recommend to the IESG that all stable and eligible documents be progressed
>along the standards track. The IESG will do whatever it would anyway, so it
>does no good to try to fineness things by endless debates about last minute
>tweaks and the resulting potential to recycle in place. If there are minor
>clarifications to make, those should be done as independent documents in the
>context of addenda to the stable documents. IPv6 as the components which
>functionally replace RFC 791, 826, etc. is complete. Solving problems that
>are still unsolved in IPv4 remains as work for continuing or future working
>groups. That does not diminish the stability of the base documents, so they
>need to progress now.
>
>On the discussion about prefixes, we need to stop revisiting decisions. The
>IETF does need to make a statement because leaving this to the RIRs is
>equivalent to leaving the fox in charge of access to the chickens. The point
>I was trying to make at the mic is that there are vocal participants in the
>RIR community that are stuck in the conservation mindset and can't seem to
>do basic math. They will agree with Thomas, Geoff, & Lea's work that without
>doing anything IPv6 will be sufficient for a number of decades, but they
>seem to loose context when the simple change of the HD from .8 to .94 buys
>an order of magnitude which results in IPv6 being sufficient for a number of
>*centuries*. That timeframe is substantially long enough that it becomes
>difficult to grasp so without a good grasp of the lifetime their
>conservation mindset steps in claiming the need to curtail wasted bits at
>every turn. The whole /56 discussion is looking to take us from centuries to
>tens (or hundreds if combined with the HD change) of millennia. What they
>fail to recognize is that this is a zero sum game where we currently have a
>balance, and moving the efficiency toward allocation removes it from
>operational deployment models that are different from the past. It is
>extremely easy to overlook the fact that some deployment models don't
>currently exist because they can't under the constraints of current
>allocation policy. This leads to a false belief that they will not appear
>over the next several centuries because we have yet to see them, when the
>reality is that it is the limited perspective policies which insure they
>will not ever appear. The IETF has to take the position of broad vision here
>and flatly state that undue conservation is detrimental.
>
>The RIR members are basically a greedy bunch. For those who have forgotten
>history, the initial 64 bit proposal exceeded the IPv6 design requirements
>by 3 orders of magnitude. At the start of the dot com boom it appeared there
>would not be enough room for comfortable waste by the service providers in
>terms of hierarchy so the entire 64 bits was dedicated to routing. Removing
>the allocation needs of 10^15 hosts meant 'more than enough' was now 'more
>than more than enough', particularly in light of the bust and consolidation.
>Even so there are continuing complaints about the /64 boundary and demands
>to relax that constraint because in historical deployment terms that number
>of bits per subnet is a waste. Never mind the issue that at some point in
>the lifetime of IPv6 the IEEE will be forced to move from 48 to 64 bit
>EUI's... Fundamentally the RIR members just don't like being told what to
>do. If left alone they will constrain network deployments to what has been
>done in the past. It is up to the IPv6 WG to set the bar to avoid the state
>where people are forced to work around the restrictive policies of a
>provider and/or LIR/RIR.
>
>Finally it takes extreme hubris to believe that IPv6 is 'THE' protocol for
>centuries or millennia to come. Technology moves on, and IPv6 will be
>replaced long before the pool is exhausted. Those who point to the phone
>system as an example conveniently overlook the rolling evolution that
>effectively reduces the window of applicability. While there may be pockets
>where things still work, in my experience equipment from 40 years ago is not
>compatible with the current network so that example should be measured in
>decades rather than centuries. Even the numbering has undergone periodic
>change, so claiming we know enough to recognize allocation waste centuries
>before the person with a bright new idea is born is the highest form of
>arrogance. The /64 decision provides more than 'more than enough' routing
>space, and the /48 decision allows flexibility at the site level without
>significant impact on the service provider's ability to waste bits
>themselves. Changing those values only makes it harder to innovate in the
>space of automated configuration of site networks and hosts, and really
>doesn't buy any useful time because we are talking about adding time to the
>point well beyond the useful lifetime of the protocol. As I said in
>draft-hain-prefix-consider-00.txt there may be business reasons to consider
>other lengths, but there are no technical reasons. We need to state that
>clearly before the IPv6 WG closes.
>
>Tony
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6 at ietf.org
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------