Re: IPv6 tranisition issues

----- Original Message -----
From: <[email protected]>
To: "Marcelo Barbosa Lima" <[email protected]>
Cc: "Pekka Savola" <[email protected]>; "Thakur, Anand"
<[email protected]>; <[email protected]>;
<[email protected]>
Sent: Friday, December 27, 2002 10:02 PM
Subject: ReN: (ngtrans) 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.

Absolutely right. People have a very large investment in IPv4 hardware and
software. Transition mechanisms will make things less painful. Quite a few
devices cannot be upgraded especially if there is only so much flash memory
for firmware upgrades.


> 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/
>
>