At 03:21 PM 4/24/00 -0400, J. Noel Chiappa wrote:
A couple of routing points, not related to NAT:
> From: Ian King <iking(_at_)microsoft(_dot_)com>
> so that it is realistic for businesses to regularly ask for assignments
> in more granular chunks; rather than grabbing a class A-size space
> "just in case", big users would be willing to request another 256 when
> the new branch office opens, then another 64 for the summer interns...
Sorry, this doesn't work - at least with IPvN (N=4,6) addresses as currently
constituted. The routing system (i.e. the software that computes paths
through the network) uses those addresses as the namespace it works on, and
to make the routing scale properly (a.k.a. "keep the network running"), those
addresses have to be aggregable.
In other words, you need to be able to have a single routing table entry that
covers a chunk of the network (such as a company's in-house network) - and
that routing table entry can't include other things as well. If a company,
etc, had addresses assigned in dribs and drabs, the way you suggest, that
company's addresses would no longer have that property.
This is because the way things are right now that we are thinking this way.
But we can change it.
We can make it like this.
1) Apply for the number of address that u need. i.e. small chunk.
2) If u need more address later on give back the original chunk and apply
for the large chunk.
I know that the 2nd case will not make many people happy i.e. they will
have to expend little more effort but then with proper implementaion even
that will be null and i think the price is not much rather than wasting
address. And with this the current routing will work fine because u will
still have the network portion for the entire corporate same.
Other namespaces, which don't have to include location information, just
identification (e.g. IEEE 48-bit numbers) work just fine with this kind of
allocation policy - but not any namespace used by path selection in a large
network.
> From: Steve Deering <deering(_at_)cisco(_dot_)com>
> making each house a TLA does not strike me as a scalable multihoming
> solution for very large numbers of houses, given the current state of
> the routing art.
The restriction has little to do with the current state of the routing art
(which is not to say that better path-selection architectures than the one
the Internet is currently using do not exist :-).
Even with the best routing system, it still couldn't support tracking large
numbers of houses as individual destinations (i.e. having individual routing
tables extries across the global scope) - even if the routers had large
enough route table memories to hold the 100's of millions of routes which
could result.
Noel