The difference between IPv6 and IPv4 is like 4 wheels versus 3 wheels. We need the
extra address space (the 4 th wheel), no brainer. What kind of suspension and brakes
we need for a smoother ride are the issues to be worked. So let us get on with it and
solve the problems.
Nara Kamath
On Wed, 23 August 2000, Thomas Narten wrote:
>
> > Sean does have a habit of asking questions that highlight the fact that
> > IPv6 isn't ready for wide-spread production deployment.
>
> While I welcome Sean's input as a backbone operator, his long-running
> disdain for IPv6 is also well known. Perhaps my previous response was
> a bit hasty from this perspective. Saying more only invites further
> misinterpretation.
>
> What this thread has made clear is that there continues to be a need
> for more education about what IPv6 does and does not do. One of the
> things that inhibits the overall discussion and accentuates the gulf
> between the two communities, is folks claiming IPv6 does X (which it
> does not do, or is an *option* rather than a *requirement*) and then
> proceeding to begin discussion based on a faulty premise. Earlier
> postings assuming trivial and automatic renumbering in IPv6 are one
> example. Another is implying that IPv6 has a "new multihoming model"
> that replaces (as opposed to supplementing) the existing models used
> in IPv4, even in cases where the IPv4 approach would appear to work
> fine. (It is probably worth noting that in the case of multihoming, it
> is far from clear that the current approaches used in IPv4 will scale
> properly, hence the reason for pursuing additional approaches in
> IPv6). It's also worth reiterating that multihoming work in IPv6 is
> still an on-going effort, and more input (especially from operators is
> needed). I encourage interested persons to join the ipng mailing list
> and participate.
>
> Finally, the ietf list is really not the best place to have a serious
> technical discussion about IPv6 shortcomings. I know of IPv6 experts
> who aren't subscribed to this list.
>
> > A more appropriate response might be to aggressively promote IPv4/IPv6
> > migration at IETF meetings. You might:
>
> > o Coordinate an IPv6 migration help desk at the IETF that will
> > help attendees upgrade their laptops to run IPv6,
>
> > o Run IPv6 (only) on the desktop machines at the IETF,
>
> > o Publish traffic statistics that compare the volume of IPv4
> > versus IPv6 usage at the IETF meetings,
>
> > o Set an objective for when the IPv6 traffic is at least as great
> > as IPv4 traffic at IETF meetings, and
>
> > o Set an objective for when IETF meetings will support only
> > IPv6.
>
> Some of these suggestions have merit, and I believe that help has been
> available at IETF meetings (though perhaps not well advertised) for
> those that want to run IPv6. (IPv6 services have been available at
> IETF meetings for some time -- if you have an IPv6 enabled on your
> laptop, it just works.) On the other hand, setting an objective for
> when IETF meetings support IPv6 only is unrealistic. IPv6 will take
> decades to completely displace IPv4. Also, the hard issues about
> disabling IPv4 at an IETF (which is what I interpret your suggestion
> of IPv6-only above to be) only works when all the end sites that
> IETFers communicate with are IPv6-enabled. We have little control over
> that.
>
> Thomas
