Subject: RE: Why IPv6 is a must?

From: TOMSON ERIC <[email-masked]>
Date: Wed, 17 Oct 2001 10:15:32 +0200

In what version of IP do you think you "tunnelize" IPv4?
Can you compare 2^32 addresses with 2^128 addresses?
Why force security in IPv4 with IPsec while security is a natural feature of IPv6?
Why force QoS in IPv4 while QoS is a natural feature of IPv6?
What about the (huge) size of the routing tables in IPv4?
What about the change of size of the IP header?
What about the complexity of the IPv4 header compared to the simplicity of the IPv6 header?
What about the options field?
What about broadcasts compared to anycasts and multicasts?
What about...
Etc.

Don't take it as an offense, but... do you really know what IPv6 is all about?

And finally : do you really think that the IETF people (et al.) built IPv6 without a preliminary good consideration?

-----Original Message-----
From: su bo [mailto:[email-masked]]

Everyone :
   I'd like to know why IPv6 is a must .
   We can use IPv4 tunnel to extend the address
spaces. We can use IPsec with IPv4. We can use MPLS on
the trunk of Internet to provide Qos. What the need of
IPv6 . 
   IPv6 is not compact with IPv4 . If pure IPv6 is
used , all the node of IPv4 is disconnected of
Internet. If IPv6 and IPv4 is used at same time .
confuse is world wide . 
   I think use IPv4 tunnul (IP_in_IP) can make an IP
address space of 2^64, and IP_in_IP_in_IP can make an
IP address space of 2^96......
   In this way we can extend IP address space to any
size that most fit the Internet's need . Lots of
Internet user connect to Internet by proxy. IP_in_IP
is no more than proxy. all the user knows the importy
node of the road , so the address is naturally
aggregatable. 
   every node on the Internet can has it own old IPv4
address . nothing changed !
   all the node of now a days Internet would be a
proxy , a router or itself just as it likes.
   all the application is not need to changed
signiphently , just configurate to support proxy. it
seem nearly all the application support proxy.
Certainly a little extend of the proxy is needed.
   All that is spuuorted by IPv4_in_IPv4 . 
   Do we really need IPv6?

---

From: [email-masked]
Date: Wed, 17 Oct 2001 13:32:17 -0400

(Note - I'm writing this as somebody who's actively pushing the deployment
of IPv6 locally. However, I felt some commentary was needed here)

> Why force QoS in IPv4 while QoS is a natural feature of IPv6?

To be fair here - note that IPSec for IPv4 and IPv6 are almost the same beast,
and similarly for QoS.  The *major* difference is that we put our collective
foot down and said "IPSec and QoS are *MUST*, not *MAY* implement" (in the RFC
sense).  Also, note that there's no requirement that IPSec be *used* in IPv6.
The AIX 4.3.3 stack will quite happily make an IPv6 connection without using
IPSec, and the base Linux 2.4 kernel doesn't even HAVE a working IPSec for v6,
and the USAGI patches for Linux are still trying to get it working.

And we still don't know how to build, deploy, *and maintain* a PKI that would
be needed to actually make this work.  Yes, there's lots of "How to store stuff
in the DNS" drafts and RFCs - but given the incredible support for proper PTR
records in the DNS, and the incredible number of sites that have actually
implemented and deployed the DNSSEC stuff... draw your own conclusions.

I'm still not convinced that anybody really understands how to do QoS (as
opposed to traffic engineering external to that, which we DO understand at
least somewhat).  The QoS field in the header suffers from the same basic
issues as source-routing of packets - they try to modify the global handling
of packets with insufficient knowledge of global conditions.  There's a
big difference between an RSVP-like system (where you politely ask a routing
system "Can you handle 100kbits/sec of teleconference traffic?" and then
base a decision on the answer) and a QoS packet ("Hi! I'm a teleconference
packet.  Route me fast!").  The two styles have drastically different
degradation/failure modes in the case of overcommittal of bandwidth - and
that's the only time that you NEED either QoS or RSVP....

> What about the (huge) size of the routing tables in IPv4?

Unfortunately, nobody's come up with a really good way to make a much
smaller representation of a directed graph with 100K+ sides.  I saw some
hand-waving about 'A6 fixes all that' on the NANOG list, but I don't recall
any really conclusive proof that it does.

Remember - the biggest problem with the routing tables is that if
a site multihomes, you need to add 2 edges to the graph - and these two
edges need to be visible to enough of the global routing table that they
actually get used to route most traffic (in other words, they need to
be seen throughout the default-free zone, or the benefit of multihoming
gets lost).  Careful use of address space out of one provider's allocation
allows you to only add one edge to the global table (and let aggregation
swallow the other provider's route), but at the expense of no longer
being provider-independent portable addresses (which means if you change
providers, you get to renumber).

> What about the change of size of the IP header?

This was an "engineering compromise".  At the time, there were a number
of people who wanted *variable* length addresses - mostly people who did
host support.  The router people wanted fixed-length to make the design of
high-speed routers easier (when you're trying to route an OC-192, the
clocking of from/to addresses is a lot easier if you don't have to worry
about them changing offset packet-to-packet).  The router guys won that
round - and then there was a long "64 or 128" debate.  Again, another
compromise - on ethernet the extra bytes didn't hurt THAT much - and
the 128-bit contingent got a big boost when it was shown that IPv6 headers
were easily compressed with a very minor modification of the standard
VJ header compression already used widely for IPv4 SLIP/PPP.

(or such is the one-paragraph summary of my fuzzy recollection of several
megabytes of working group email - the general flavor is there, anyhow ;)
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Oct 2001 08:58:58 +0200

[email-masked] wrote:

> ... The QoS field in the header suffers from the same basic
> of packets with insufficient knowledge of global conditions.

Your text mainly refers to IntServ about which I make no comment. But the diffserv
header field (formerly known as TOS in IPv4, known as Traffic Class in IPv6)
is explicitly *not* global - it is meaningful per domain, and only makes
sense in a domain that has been appropriately configured. See RFC 2474, 2475
and 3086 for more.

   Brian

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 18 Oct 2001 02:31:40 -0500

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 18, 2001 1:58 AM
Subject: QOS [was Re: Why IPv6 is a must?]

> sense in a domain that has been appropriately configured. See RFC 2474,
2475

The QoS field in IPv8 (formerly known as TOS in IPv4) is divided into two
4-bit fields. This expands the addressing of the existing IPv4 Internet by a
factor of 16, with no change to the existing infrastructure. Those same 4
bits
then carry over into IPv8 and IPv16 Addressing. The 2,048 address blocks
freely allocated to IPv8 as shown below, are actually each much larger than
the existing IPv4 address space, which needs to be replaced because of the
poor management of the resource and the unfair allocation policies.

Jim Fleming
http://www.in-addr.info
3:219 INFO
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt