Tony, you said it all, and I for one have no more to say on this and we should take your mail to heart and do exactly what you state.
Regarding making statements about deployment all the IETF can do is make a statement of implementation state. Further on that mission is in process in the market and in process that also will do verification and one of them is the IPv6 Forum Logo program, for part of what is required, and that is going to be expanded. This will support equally both government and industry and world wide. thanks for your time to type all this in and thoughts, /jim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Tony Hain > Sent: Wednesday, August 03, 2005 8:29 AM > To: ipv6@ietf.org > Subject: potpourri > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
