[lkml]   [1996]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectIPv6 and the Future

I've been silently reading the IPv6 thread, and decided to speak up. I've
listed my limited observations on IPv6, to help explain it to some people
on this list (mostly the ones who were lurking like me, and who probably
haven't read much on it.) My question, which is not a nuts and
bolts kernel question, is at the bottom.

I just read a book on IPv6 (won't mention the title). The general
impressions I observed were:

1. Increased address size for:
a. massive address supernetting (exponentially smaller routing tables)
based on what amounts to ISP prefixes. The idea is to have one prefix per
ISP, which would translate to 1, or less than 1, roting entry per ISP in
backbone routers.
b. each way to access a host will have a seporate IP address. For
example, if a host is connected through multiple ISPs... and an address
that is only vaild on the LAN.
2. Various updates to ICMP which support multicast routing, peer
discovery (without ARP), and router discovery.
3. My main question here: flow lables. I've been working a lot with
frame relay and have been learning some things about ATM. I was pretty
much sold on the idea of ATM. But, after reading the book, I learned just
how bad the war between switching and routing is.

I work at an ISP that happens to favor switching. I've heard serious
reasons why switching would be better than routing. (and several
definitions of 'better'). I'm looking for a good argument in favor of
routing. The 'stateless' arguments I've seen don't seem like much of a
plus if every packet has to be routed.

I apologize if this message is not fit for this list. It does seem more
informative than some of the other ones I've seen, and fairly relevant to
one of the ongoing threads here. Also, IPv6 is still in development for
the kernel.


Jason Eggleston

 \ /
  Last update: 2005-03-22 13:38    [W:0.045 / U:1.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site