ReN: IPv6 tranisition issues

[n***@arc.net.my]

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/

[Keith Moore]

Post by n***@arc.net.my
Show me the IPv6 killer-app!.

It looks like you're trying to make IPv6 deployment fit into some model
in your head that requires a single killer app, rather than trying to
understand why specific interests would want to use IPv6 and whether
it is economically feasible for those interests to use IPv6
(possibly tunneled over IPv4). I don't see a single killer app for
IPv6; rather I see lots of groups (some larger than others) taking
advantage of IPv6's improved functionality. e.g. mobility,
linear address space (and lack of interference from NATs), ability
to interoperate with 3G mobile phones, etc.

Since IPv6 is incrementally deployable from the endpoints, it is not
necessary for IPv6 to have a killer app to drive deployment in order
for IPv6 to be successful.

Keith

[Michael R. Cole]

----- Original Message -----
From: "Keith Moore" <***@cs.utk.edu>
To: <***@arc.net.my>
Cc: <***@sunroof.eng.sun.com>
Sent: Friday, December 27, 2002 11:19 PM
Subject: Re: ReN: (ngtrans) IPv6 tranisition issues

Post by Keith Moore

Post by n***@arc.net.my
Show me the IPv6 killer-app!.

It looks like you're trying to make IPv6 deployment fit into some model
in your head that requires a single killer app, rather than trying to
understand why specific interests would want to use IPv6 and whether
it is economically feasible for those interests to use IPv6
(possibly tunneled over IPv4). I don't see a single killer app for
IPv6; rather I see lots of groups (some larger than others) taking
advantage of IPv6's improved functionality. e.g. mobility,
linear address space (and lack of interference from NATs), ability
to interoperate with 3G mobile phones, etc.
Since IPv6 is incrementally deployable from the endpoints, it is not
necessary for IPv6 to have a killer app to drive deployment in order
for IPv6 to be successful.
Keith

The 2 killer applications are going to be:

1. Mobile systems. In IPv6 the right half of an address will be globally
unique to the mobile device and the left half will be unique to the actual
pathway to the device. This will simplify roaming and changing Internet
Service Providers, which is a form of roaming.

2. New Internet Service Providers. The left half of the IPv6 address would
be assigned by the ISP and the right half would come from the MAC-48 or
EUI-64 of the customers hardware. This would also make connection sharing a
LOT simpler. If a user wants to hide their MAC-48s or EUI-64s from the
public 'net, they can use a made up right half that is manually assigned
using unused Organizationally Unique Identifiers with the u-bit set equal to
zero.

I have found that some NAT boxes, such as the software NATs from Sybergen,
are a lot better than others. There are also some crummy NAT boxes such as
Wingate, which worked with NONE of my applications. A NAT box is just simply
a retooled router, just that some a better and some are worse.

Likewise, there are SOME IPSEC products than can traverse a NAT box and
some that cannot. Software quality varies all over the place. That is, you
should ALWAYS test and compare different vendors in order to find which
implementation is best for your system.

Mike Cole, ***@earthlink.net

[Keith Moore]

Post by Michael R. Cole
A NAT box is just simply
a retooled router,

that's a truly bizarre statement. I suppose it's true from a
hardware perspective, but it's like saying that a NAT box is
just a retooled computer with a couple of network interfaces -
true, but irrelevant to the question at hand.

Post by Michael R. Cole
just that some are better and some are worse.

all NATs break applications. some NATs know about a few more
protocols than others, but no NAT can handle every possible protocol,
many protocols simply cannot be made to work transparently through NAT.

Keith

[Michael R. Cole]

----- Original Message -----
From: "Keith Moore" <***@cs.utk.edu>
To: "Michael R. Cole" <***@earthlink.net>
Cc: <***@sunroof.eng.sun.com>
Sent: Tuesday, December 31, 2002 12:28 AM
Subject: Re: ReN: (ngtrans) IPv6 tranisition issues

Post by Keith Moore

Post by Michael R. Cole
A NAT box is just simply
a retooled router,

that's a truly bizarre statement. I suppose it's true from a
hardware perspective, but it's like saying that a NAT box is
just a retooled computer with a couple of network interfaces -
true, but irrelevant to the question at hand.

Post by Michael R. Cole
just that some are better and some are worse.

all NATs break applications. some NATs know about a few more
protocols than others, but no NAT can handle every possible protocol,
many protocols simply cannot be made to work transparently through NAT.
Keith

Your definition of the word break must be different than the one in the
dictionary. If an application works with a NAT box, then it is NOT BROKEN!
Your claim would also say that a timesharing system with only 1 public IPv4
address would not work which is what a cone NAT mimics. That is, a cone NAT
fools that public Internet into thinking that a LAN or other subnet is in
actuality a single machine. At any rate, a NAT box is a patch that gets
around the problem that a good sized chunk of the IPv4 address space was
wastefully allocated to the original players at essentially zero cost.

Maybe your first experience with a NAT box was with a really crummy one? If
that is your only experience or of you have no experience with NAT boxes,
then you have no business crticizing them. Some NAT software that I have
tried was absolutely horrible.

I am not trying to say that the better NAT boxes will work with ALL
applications. Somehow, the cable companies are able to use them at their
headends without breaking applications. However, I have noticed that
enterprise-class NAT boxes use a server-client setup so that applications
are not really aware or can tell that they are indirectly connected to the
Internet. Symmetric NAT boxes probably do work better in part because they
mimic a timesharing system with one public IPv4 address for each user.

Of course, some applications are very picky about what they will eat.

MIke Cole, ***@earthlink.net

[Randy Bush]

Post by Michael R. Cole
Of course, some applications are very picky about what they will eat.

yup, they expect silly things like tcp/ip.

look, many of us use nat boxes. they do break perfectly conformant
applications. and they can be especially delightful in the presence
of bog standard things like fragmentation.

can we please stick to technology, not hyperbole? thanks.

randy

[Keith Moore]

Post by Michael R. Cole
If an application works with a NAT box, then it is NOT BROKEN!

all NAT boxes break some applications. if it happens that you are
using a NAT box with a set of hosts that are running only a set of
specific applications that are known to work with that NAT box,
fine. but NAT boxes are sold as general-purpose internet connection
sharing devices and security enhancers and they are neither of these.

I've spent a great deal of time trying to get distributed apps to work
over NAT boxes - basically it is often infeasible to do so.

private mail would be better if you want to discuss this further;
it's not on topic for ngtrans.

Keith

[n***@arc.net.my]

Keith,

Thank you for your input. I have looked at various angles on this but
end up at a dead-end every time. As in my earlier postings looking at
IPv6 and the many obvious advatages in QoS, multicast, routing, address
space, mobility, etc, there is always an IPv4 solution for this. The
solution may be a dodgy patch, not as streamlined or designed from the
ground up as the IPv6 version, but it works and John Q. Public is not
going to rush out now or even look at including an IPv6 subnet in his
current IPv4 setup.

The key word here is 'now'. Perhaps later or of course when 3G networks
are available, but when?. A good example is to look at the Y2K issue.
Most companies started addressing the issue at the last minute only. And
this could possibly be the path with the IP address shortage issue.

So what compelling enough reason can be presented to Mr. John here for
him to even consider IPv6. Even start looking at a staggered transition
plan. Or even hardware/software developers -most of these are either
from Europe and Japan.

Regards,
-nick/

[Keith Moore]

many businesses are already working on IPv6 transition because of the
operational problems caused by NATs. John Q. Public may well want to
start using IPv6 when he realizes that it makes it possible for him
to access his home machines, printer, baby-cam, etc. from elsewhere
in the network, including his PDA.

but I don't think there will be a single compelling reason to use
IPv6. looking for a killer app for IPv6 is like looking for a
killer app for email or fax.

Keith

[Michael R. Cole]

----- Original Message -----
From: <***@arc.net.my>
To: "Marcelo Barbosa Lima" <***@cpqd.com.br>
Cc: "Pekka Savola" <***@netcore.fi>; "Thakur, Anand"
<***@hpsglobal.com>; <***@sunroof.eng.sun.com>;
<***@i2r.a-star.edu.sg>
Sent: Friday, December 27, 2002 10:02 PM
Subject: ReN: (ngtrans) IPv6 tranisition issues

Post by n***@arc.net.my
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.

Post by n***@arc.net.my
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/

[Thakur, Anand]

Hi,
I have been following this discusson on NAT since it started, though i have
not contributed in any way.
But at this point of time i would like to point out that our company has
been using NAT for 5-6 years now and we have not encountered any problems
(as far as breakage of applications) is concerned. Could you please give me
some examples of the applications that are broken by the usage of NAT?

regards
Anand Thakur
HCL Perot Systems (A SEI CMM Level 5 Company)
Plot No 3, Sector 125, NOIDA (UP)-201301, India
* Tel [phone], X3348 (EPABX)
mobile:[phone]

-----Original Message-----
Sent: Tuesday, December 31, 2002 4:50 PM
Subject: Re: ReN: (ngtrans) IPv6 tranisition issues
----- Original Message -----
Sent: Tuesday, December 31, 2002 12:28 AM
Subject: Re: ReN: (ngtrans) IPv6 tranisition issues

Post by Keith Moore

Post by Michael R. Cole
A NAT box is just simply
a retooled router,

that's a truly bizarre statement. I suppose it's true from a
hardware perspective, but it's like saying that a NAT box is
just a retooled computer with a couple of network interfaces -
true, but irrelevant to the question at hand.

Post by Michael R. Cole
just that some are better and some are worse.

all NATs break applications. some NATs know about a few more
protocols than others, but no NAT can handle every possible protocol,
many protocols simply cannot be made to work transparently through NAT.
Keith

Your definition of the word break must be different than the one in the
dictionary. If an application works with a NAT box, then it is NOT BROKEN!
Your claim would also say that a timesharing system with only 1 public
IPv4
address would not work which is what a cone NAT mimics. That is, a cone
NAT
fools that public Internet into thinking that a LAN or other subnet is in
actuality a single machine. At any rate, a NAT box is a patch that gets
around the problem that a good sized chunk of the IPv4 address space was
wastefully allocated to the original players at essentially zero cost.
Maybe your first experience with a NAT box was with a really crummy one?
If
that is your only experience or of you have no experience with NAT boxes,
then you have no business crticizing them. Some NAT software that I have
tried was absolutely horrible.
I am not trying to say that the better NAT boxes will work with ALL
applications. Somehow, the cable companies are able to use them at their
headends without breaking applications. However, I have noticed that
enterprise-class NAT boxes use a server-client setup so that applications
are not really aware or can tell that they are indirectly connected to the
Internet. Symmetric NAT boxes probably do work better in part because they
mimic a timesharing system with one public IPv4 address for each user.
Of course, some applications are very picky about what they will eat.

[Jeroen Massar]

First I would like to wish everybody a happy and fruitful 2003.
Asian Pacific people are already in 2003 there now I think as it's 16:00
CET
Oh and ofcourse happy IPv6'ing ;)

Post by Thakur, Anand
Could you please give me
some examples of the applications that are broken by the usage of NAT?

NAT didn't break it, but it does make sure one can't use it.

- Conferencing applications (read: Netmeeting)
- *ANY* peer to peer (p2p) application without a central/redir service.

Actually any application where you want to make contact
directly to the other service (end to end ;)

And there is one of the biggest reasons for IPv6:
so we have enough IP-space to give every IP-capable-service
in the world (universe ? ;) a globaly routable IP address so
that it can communicate with every other service in the world.

And another cool thing of IPv6 is the perdefacto multicast.
Which is a thing I am going to be pushing the coming year,
more about that soon(tm) ;)

Greets,
Jeroen

[Fred L. Templin]

Post by Jeroen Massar
First I would like to wish everybody a happy and fruitful 2003.
Asian Pacific people are already in 2003 there now I think as it's 16:00
CET
Oh and ofcourse happy IPv6'ing ;)

Huh? It was still 2002 when I submitted the -09 version of the
ISATAP spec to the repository. (Guess I need to be more aware of
what timezone I'm in!) Anyone interested can view the latest
draft version at:

http://www.geocities.com/osprey67/isatap-09.txt

Post by Jeroen Massar
Greets,
Jeroen

Happy New Year to all,

Fred Templin
***@iprg.nokia.com

[Thakur, Anand]

Wish you and your loved ones a Very Happy and Prosperous New Year as well

regards
Anand Thakur
HCL Perot Systems (A SEI CMM Level 5 Company)
Plot No 3, Sector 125, NOIDA (UP)-201301, India
* Tel [phone], X3348 (EPABX)
mobile:[phone]

-----Original Message-----
Sent: Wednesday, January 01, 2003 5:56 AM
To: Jeroen Massar
Subject: Re: ReN: (ngtrans) IPv6 tranisition issues

Post by Jeroen Massar
First I would like to wish everybody a happy and fruitful 2003.
Asian Pacific people are already in 2003 there now I think as it's 16:00
CET
Oh and ofcourse happy IPv6'ing ;)

Huh? It was still 2002 when I submitted the -09 version of the
ISATAP spec to the repository. (Guess I need to be more aware of
what timezone I'm in!) Anyone interested can view the latest
http://www.geocities.com/osprey67/isatap-09.txt

Post by Jeroen Massar
Greets,
Jeroen

Happy New Year to all,
Fred Templin