RES: IPv6 tranisition issues

  Hi Nick,

 You are forgetting the mobility. Support to mobility in IPv6 is more optimized and stateless autoconfiguration resources are a step ahead (if AH is used, is enough secure. ARP and gratitious ARP are problems). Routing optimization in IPv4 is very insecure for me. This feature is fundamental to 3GPP develepment (roamming between differents networks), por example. Besides, ICMPv6 (authenticated ping, for example) and routing protocols can be more secure. NAT provides many problems to IPSec. So, IPv6 provides many advantages against IPv4... 
regards,

   Marcelo Lima
   

-----Mensagem original-----
De: [email protected] [mailto:[email protected]]
Enviada em: sexta-feira, 27 de dezembro de 2002 09:34
Para: Thakur, Anand
Cc: [email protected]; [email protected]
Assunto: Re: (ngtrans) IPv6 tranisition issues


Thank you all for your inputs on this. The points I presented were
summarized from one of my presentation slides on IPv6 and issues faced
in IPv6 transition. I understand all the points presented and am fully
behind IPv6. It is when you are proposing on a regulatory/governmental
level, there has to be some substance to the claims and rebuttals.
Hence, I am looking for a good academic/technical paper on the 'Great
IPv4 vs. IPv6 Debate'.

This is slightly pro-IPv4. Basically IPv6 addresses 4 main points:

1.Address space. For IPv6 opponents there are patches like CIDR, NAT,
DHCP, etc to address this issue. Besides 3GPP (which is not here as
forecasted), there is no other killer-application that is reason enough
to look at IPv6 seriously. So in the mean time why rush is the question
-'if it ain't broke, why fix it'.

2. QoS. Beside the obvious differences in the respective IP header
labels, QoS implementation between the two are rather similar. In fact
QoS flow tagging in both IPv4 (TOS) and IPv6 (Flow) are similar where an
8-bit label is used (although IPv6 allows for a 24-bit label) so as for
flow tagging to operate in both environments. Both protocols will
support MPLS tagging (TE/QoS/IP-VPN) and RSVP for QoS implementations.
Of course the IPv6 QoS solution is more streamlined and much improved,
but is this reason enough to switch to/develop applications/etc in IPv6 now?

3. Multicast/Anycast. With the exception of anycast and the major
improvement on multicast in IPv6, other advancements other than
addressing structure/capabilities again is not a valid enough reason for
IPv6 multicast support. Anycast is still being further developed. Areas
that need addressing are router-processing power (for the additional
multicast tables) and the management/set-up/operation of IGMP is complex
amongst others.

4. Security. Beside the inclusion of AH and ESP at the IP level instead
of at the higher layers, there are only slight differences between IPSec
implementations between IPv4 and IPv6. IPSec, which is optional on IPv4,
does not ensure an 'end-to-end' implementation unlike the mandatory
version on IPv6. But is this realy necessary/important?

With the exception of points 1 and 4, there is no real application for
QoS and multicast in the big bad public Internet. These are usually
restricted to within a closed network or in an R&E environment. So John
Q. Public does not really appreciate/understand/use these in everyday
applications.

These are some of the questions (beside the ones I highlighted) that
need to be answered when asked 'Why now?'. Of course these IPv4 issues
will one day need to be addressed, but not today. Perhaps in the future
and perhaps there will be another next generation IP to solve these.

So with points like this put forward, maybe we might be looking at
promoting/developing IPv7/8/9......

Best regards,

-nick/