deepak at ai.net
Fri Aug 8 17:53:23 CDT 2008
According to: http://www.netbsd.org/docs/network/ipv6/
* Larger IP address space. IPv4 uses only 32 bits for IP address
space, which allows only 4 billion nodes to be identified on the
Internet. 4 billion may look like a large number; however, it is less
than the human population on the earth! IPv6 allows 128 bits for IP
address space, allowing 340282366920938463463374607431768211456 (three
hundred forty undecillion) nodes to be uniquely identified on the
Internet. A larger address space allows true end to end communication,
without NAT or other short term workarounds against the IPv4 address
shortage. (These days NAT is a headache for new protocol deployment and
has scalability issues; we really need to decommission NAT networks for
the Internet to grow further).
* Deploy more recent technologies. After IPv4 was specified 20
years ago, we saw many technical improvements in networking. IPv6
includes a number of those improvements in its base specification,
allowing people to assume these features are available everywhere,
anytime. "Recent technologies" include, but are not limited to, the
o Autoconfiguration. With IPv4, DHCP exists but is optional.
A novice user can get into trouble if they visit another site without a
DHCP server. With IPv6, a "stateless host autoconfiguration" mechanism
is mandatory. This is much simpler to use and manage than IPv4 DHCP.
RFC2462 has the specification for it.
o Security. With IPv4, IPsec is optional and you need to ask
the peer if it supports IPsec. With IPv6, IPsec support is mandatory. By
mandating IPsec, we can assume that you can secure your IP communication
whenever you talk to IPv6 devices.
o Friendly to traffic engineering technologies. IPv6 was
designed to allow better support for traffic engineering like diffserv
or intserv (RSVP). We do not have a single standard for traffic
engineering yet, so the IPv6 base specification reserves a 24-bit space
in the header field for those technologies and is able to adapt to
coming standards better than IPv4.
o Multicast. Multicast is mandatory in IPv6, which was
optional in IPv4. The IPv6 base specifications themselves extensively
o Better support for ad-hoc networking. Scoped addresses
allow better support for ad-hoc (or "zeroconf") networking. IPv6
supports anycast addresses, which can also contribute to service
o and more.
* A cure to routing table growth. The IPv4 backbone routing table
size has been a big headache to ISPs and backbone operators. The IPv6
addressing specification restricts the number of backbone routing
entries by advocating route aggregation. With the current IPv6
addressing specification, we will see only 8192 routes on the
* Simplified header structures. IPv6 has simpler packet header
structures than IPv4. It will allow future vendors to implement hardware
acceleration for IPv6 routers easier.
* Allows flexible protocol extensions. IPv6 allows more flexible
protocol extensions than IPv4 does, by introducing a protocol header
chain. Even though IPv6 allows flexible protocol extensions, IPv6 does
not impose overhead to intermediate routers. It is achieved by splitting
headers into two flavors: the headers intermediate routers need to
examine, and the headers the end nodes will examine. This also eases
hardware acceleration for IPv6 routers.
* Smooth transition from IPv4. There were number of transition
considerations made during the IPv6 discussions. Also, there are large
number of transition mechanisms available. You can pick the most
suitable one for your site.
* Follows the key design principles of IPv4. IPv4 was a very
successful design, as proven by the ultra large-scale global deployment.
IPv6 is "new version of IP", and it follows many of the design features
that made IPv4 very successful. This will also allow smooth transition
from IPv4 to IPv6.
* and more.
What I'd like to say is that someone here is playing fast and loose with
"mandatory" and "required" (or its true for same definitions of
mandatory or required). A couple of these jumped out at me like, "Only
8192 routes on the DFZ" and other things.
Rather than jumping down someone's throat here, are these assumptions
rampant (or even accurate)? We came across this as we were trying to
enhance our own Ops groups documents to share with customers, and well,
I don't think we want to share this. ;)
More information about the NANOG