httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: sequence numbers
Date Fri, 15 Aug 1997 22:24:02 GMT
Yeah this is definately off-topic ... but ... hey we don't do that too
much :)

No it's just apparently better.  It's not actually better.  There's
nothing that IPv6 can do that CIDR can't.  Just because you can dictate
that there is going to be structure doesn't mean that there will be
structure.  Look at the current situation with CIDR, the reason there
isn't enough aggregation is not because the structure is bad, it's just
that people don't want to aggregate.  Those are reasons which don't
disappear with v6. 

Suppose I'm Wired.  I want three or four redundant network connections.  I
*cannot*, under v4 w/CIDR or v6, allow my network announcements to be
aggregated.  If I allow them to be aggregated then I do not have a
redundant connection.  So I will be unaggregated in both v4 and v6. 

Switching to v6 addresses means that the swamp and toxic waste dumps
finally get cleaned up, by force.  That'll reduce the routes by 15k or
so... which is a good improvement.  But not a fundamental change. 

"well known addresses" ?  Since when has it offered that?  That's also not
something that requires v6.  You can do that equally easy with v4.  It
requires *client side support* in both cases.  And if you think it's taken
a while for vendors to start shipping CIDR-ready operating systems, just
imagine how long it's going to take for v6 to be implemented properly.

And finally ... the legacy ipv4 address space exists as a subspace of v6. 
So ... v6 is at least as difficult to route in the defaultless core.

The best solution to the routing problem is to have the protocols enforce
aggregation dynamically.  Vadim Antonov (of Pluris) has a proposed
protocol that does this called "trivial ip".  In his proposal address
renumbering is a core part of the protocol and your address is dynamically
renumbered as your network grows.  Routing forms the hierarchy that
everyone wants automatically.  At any point in time each lan essentially
has the "right" number of addresses (next higher power of two).  Routing
essentially amounts to knowing a handful of prefixes for your peers. 
Multicast tree-pruning is a simple operation (finding the longest common
prefixes).  It relies on a secure DNS implementation, with dynamic
updating.

Dean

On Fri, 15 Aug 1997, Philip A. Prindeville wrote:

> > Date: Fri, 15 Aug 1997 14:45:56 -0700 (PDT)
> > From: Dean Gaudet <dgaudet@arctic.org>
> > To: new-httpd@apache.org
> > Subject: Re: sequence numbers
> 
> > P.S. I'm not a fan of IPv6.  I don't think it solves the problems people
> > think it solves.  In particular it does *not* solve the problem of having
> > global routing tables with 50k routes in them.  It exacerbates that
> > problem.  And there's no immediate need for ip address space.  There are
> > still ISPs wasting entire /24 prefixes on ISDN customers with two machines
> > in their house.  I'm not alone with these opinions ... and I doubt we'll
> > see IPv6 replacing IPv4 for another five years. 
> 
> Well, it does offer a better approach to the problem with the number
> of routes...
> 
> Because you have a larger numbering space, you can structure it more.
> More structure means more levels of heirarchy, so that you can do better
> aggregation (which is why CIDR was deployed in the first place).
> 
> CIDR, after all, introduced a 4th level of structure:  CIDR block,
> network number, subnet number, host address.  Only problem is that
> goons like Sun are still shipping machines that don't understand
> CIDR.
> 
> Another thing it offers is well-known addresses, so that you could
> address a group of machines in a URI (for instance) that have a
> common sub-tree, instead of having multiple URIs for the same file.
> You could then route to the best (or "closest", or "least congested")
> server.
> 
> I think this is not the best place to discuss this.
> 
> -Philip
> 


Mime
View raw message