httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philip A. Prindeville" <phil...@enteka.com>
Subject Re: sequence numbers
Date Sat, 16 Aug 1997 02:22:00 GMT
> Date: Fri, 15 Aug 1997 15:24:02 -0700 (PDT)
> From: Dean Gaudet <dgaudet@arctic.org>
> To: new-httpd@apache.org
> Subject: Re: sequence numbers

> 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. 

Well, given that any sort of structuring is going to impact your
utilisation of the address space, and that 32 bits is a limited
amount of space, CIDR gives you more flexibility to structure
your addresses.  So the structure isn't bad, you just have a very
low ceiling in IPv4...

> 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. 

Whoa!  That's not an addressing issue.  That's a question of what
metrics you use to advertise yourself out in BGPv4.  Now if you want
to have your traffic flow over several of those connections (load-
balancing) simultaneously then things get more complicated, but still
do-able.  It most cases, it involves the cooperation of the IXC and
tweaking route-maps within his infrastructure:  you advertise an
attractive low metric to the IXCs subscribers, but the IXC in turn
advertises it at a high metric to his peers.

Nothing to do with aggregation.

> 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.

See RFC 1884, section 2.5 on the "Anycast addresses".

> 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.

IPv4 will be a vestige.   Hosts will be "dual-spaced" for a limited
amount of time.

> The best solution to the routing problem is to have the protocols enforce
> aggregation dynamically.  Vadim Antonov (of Pluris) has a proposed

A protocol has two methods at its disposal: architecture and policy.
You don't want to confuse them, and you don't want to architect
something that you might want to change later.  Such things are
better expressed in policy.  Policies change.  Architectures rarely
do.

> 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. 

Isn't that what CIDR would be in the best case?

> Multicast tree-pruning is a simple operation (finding the longest common
> prefixes).  It relies on a secure DNS implementation, with dynamic
> updating.

> Dean

I'll have to put it on my list of things to read, which is currently
around 8,753 and growing... :-(

But it sounds to me like you could do many of these things with
source routes, where every address in the list specified the next
level of scope, or granularity.  Kind of painful to manage in the
case of multicast flows.

-Philip

Mime
View raw message