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@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
