ReN: IPv6 tranisition issues

Yes, in a typing fury I forgot/missed the IPv6 solution for mobility.
IPv6 is streamlined and designed for mobility in mind. Again there are
the patches in IPv4, although riddled with triangular routing issues.
But then again is there anyone really into mobile IP? And I use NTT
DoCoMo and likes in Japan as examples for this and not a 'hotspot' cafe
answer on 802.11.

Right now for IPv6 to really take off we need that killer-application,
which what 3G was supposed to be. But forecasts on mobile service
providers to roll-out their 3G networks with all the
commercial/licensing/bidding issues, this seems quite uncertain. From
this point of view, as long as the mobile SP is hanging on to 2G and
patching up to 2.5G, promoting and further developing IPv6 applications
will be difficult.

On the 486-Pentium analogy. I think it is called 'software
burst-technology'. Where it is the application/software growing need for
more speed, memory, and processing power that drives and pushes the
hardware vendors further. You know you can still run a *BSD/Linux
mail-server on a 486 and not crash like its M$ counterpart on a
souped-up Pentium. 

I was reading a review on QNX as the almost perfect operating system
available but that is it -you cannot do anything else on it. Currently
we have set-up a commercial IPv6 service available here. But as the
i386/QNX box, the IPv6 network is collecting dust, well beside us
playing and experimenting with mobility and transition solutions.

In forming a steering committee to address transition I approach it this
way. No need to be a 100% native IPv6 network with full suite of IPv6
functionality - QoS, multicasting, mobility, authentication, ESP, etc.
We cannot and should not pack-up and store away IPv4. Staggered
transition migration and deployment is recommended starting with a
subnet or even a host.

At least implement an IPv6 service offering and start promoting,
creating awareness, transition planning, and even perhaps draft
national/regional policies. For both end-user and SP IPv6 networks, be
it tunneled, NAT-PT, ISATAP, or native (even in a closed environment),
this will naturally evolve -just look at our own IPv4 networks from
where we started.

From this we can shorten the time gap between the 'IPv6 island in an
IPv4 ocean' and 'IPv4 island in an IPv6 ocean' scenarios. IPv4 may never
be fully replaced -although some say around 2030-2040. Another analogy.
Remember that the introduction of Windows 95 (e.g. dual stack) started
phasing out 16-bit applications (e.g. IPv4)to 32-bit (e.g. IPv6). Almost
8 years later, you really can't run these 16-bit applications anymore
without emulators/simulators  (e.g. translation gateways/tunnels), older
O/Ss (e.g. legacy IPv4 equipment) or loosing processor efficiency. Sure,
there could have been quite a lot of things we could have still done on
a Windows 3.11 platform, but then what about multithreading, preemptive
multitasking, parallel processing, long-filenames (remember 8:3),
separate address space, etc. I am sure you can still find some and run
16-bit software today, but really, who wants to.

But in the analogy above the driving factor is the O/S and the many
applications (killer and non-killer included) that rolled-out shortly
after, which lack in the IPv6 world. Sigh. Show me the IPv6 killer-app!.


Best regards,
-nick/