(Note - I'm writing this as somebody who's actively pushing the deployment
of IPv6 locally. However, I felt some commentary was needed here)
On Wed, 17 Oct 2001 10:15:32 +0200, TOMSON ERIC said:
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?
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
pgpAbXqWFw4zl.pgp
Description: PGP signature