[ppml] Fwd: potpourri

[Bill Manning]

interesting ideas from the IETF IPv6 WG....



Begin forwarded message:

> From: "Bound, Jim" <Jim.Bound at hp.com>
> Date: August 3, 2005 9:37:35 PDT
> To: "Tony Hain" <alh-ietf at tndh.net>, <ipv6 at ietf.org>
> Cc: Subject: RE: potpourri
>
> 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: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On
>> Behalf Of Tony Hain
>> Sent: Wednesday, August 03, 2005 8:29 AM
>> To: ipv6 at 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 at ietf.org
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 at ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 7150 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050803/f478fd7d/attachment.bin>