I have been observing the current v4/v6 discussion.The v4- scalability problem is not solved just by flocking to v6. The RAWS report even mentioned the expectation that the problem would increase at least by factor 4. And this is not a surprise: v4 and v6 are both committed to the same paradigm namely "address aggregation" which is the true cause of the problem (and not multihoming, natural growth, end user device diversity,etc. which only report the problem). I showed how to avoid this problem by sketching a routing protocol which yields a sparsed internet network view such that by the help of 2 geo-data octets forwarding at least to the destination square degree can be done without the prefix-based routing table, instead by means of a single-index table lookup.My problem: How to squeeze out 2 octets in the IP header? By means of an optional parameter? By means of an outer header just as is granted to LISP? By some shim (a single MPLS label has even 4 octets !!! ) The next possibility is by means of IPv6. Note, 8 octets are enough to identify any square centimeter on the surface of this planet. With the remaining 8 octets a hell of a lot network elements can be identified on each such square centimeter. By assuming that only 1 router is hereby included (in this destination square centimeter), routing from ingress to egress can be done by one single table lookup at each router! ( I am sure that less granularity would do as well :-). This also means: No SINGLE address prefix building is needed any more ! (Exception: For building tunnels as to interconnect isolated knowledgable subnetworks during an initial phase of deployment) I will continue to seek and to hope getting a chance as to demonstrate my concept. Yes, geo-data plays an important role, but not the fundamental one (obviously there are other geo concepts as well). The fundamental difference with the current paradigm however is the automated topology aggregation. I am still about to make progress and have regretfully learned that hierarchy a la PNNI or NIMROD is not a big help. I know that I hereby take an "out-law"-position. I do NOT say "forget Dijkstra", instead "improve and use Dijkstra for the construction of aggregated topologies". Yes, I do say " away with address aggregation and away with distance vector". A GOOGLE MAP user will understand my "vision" as well as my disappointment about PNNI/Nimrod :-) The benefits are much more than the elimination of the scalability problem. A routing technology could be enabled such that loops become yesterday's ghosts and the TTL, as used today, a fossil from the past. Multipath and even much more than ipfrr is doing could be enabled intra- AND inter-domain wise. Multihoming can adequately and easily be done by employing different dest.geo-data of the respective dest.router. Address depletion is not a problem. The end device must be unique just at any dest. router. Mobility becomes very easy. The routing churn is not of O(r²) with r = distance to the originator, but of 1/O(r²) Traffic balancing TE could be done while SEEing and dealing with that traffic originating subnetwork whose traffic would pass the current router, and finally: young students may get a powerful basis for developing their own ideas. Heiner
