Hi Fred, You wrote:
> Sorry for the delay, but I had to dig pretty deep to find this: > >> Fred Templin disagreed with your text, wanting IPv4 and IPv6 >> solutions. > > I don't disagree with what Tony said, however, there is quite > a bit left to consider in what he _didn't_ say. I apologise for misrepresenting your position. > Tony didn't > say, for example, that we can expect the existing global IPv4 > deployment to be decommissioned in the coming N years (for any > value of N). He also did not say that IPv4 will have no roll > to play in the IPv6 routing scaling solution. My understanding of the text Tony proposed was that it would be acceptable for the RRG solution to be developed for IPv6 only. I understand this as meaning that the RRG would be doing its job if it allowed the the IPv4 routing scaling problem (increased DFZ router costs, instability, lack of multihoming for large numbers of end-user networks etc.) to continue to grow until a significant proportion of end-users adopted IPv6-only services. Since I can't see how large numbers of end-users will have IPv6-only services in the next decade, and because I assume that the IPv4 routing scaling problem will accelerate and become an excessive (and I think avoidable) burden on all Internet users, I proposed an alternative. This would commit the RRG to recommending a solution o the IPv4 problem for development and deployment ASAP, and doing our best to facilitate a solution to the IPv6 problem in sufficient time that no serious problem develops. This is a much longer time frame with more technical flexibility for a solution, and perhaps no need by 2009-03 to make a precise recommendation on the IPv6 solution. > In my perfect world, we would roll out the big iron to > flat-route the global IPv4 address space, while at the same > time we map-and-encaps the dickens out of IPv6. So your ideal is no architectural enhancement for IPv4. Every DFZ router would be replaced every few years by some even more humongous thing from Cisco or Juniper with tens and later hundreds of gigs of RAM, and multiple CPUs somehow working to keep the BGP process working cohesively, despite having a dozen or so peers to chat to about several million prefixes. I think that would be indistinguishable from letting the IPv4 routing scalability problem fester, and having all Internet users pay for these fabulously muscled routers, betting that by some means, (such as an imaginary chicken laying a real egg which grows into a real chicken), enough end-users will be happy with an IPv6-only service that the IPv4 debacle will come to an end in some acceptable way. I thought the aim of the RRG work was to prevent such massively expensive technical mistakes. > The existing > IPv4 services would then remain highly available while new > services are rolled out using IPv6 and w/o thrashing the > routing system. IPv6/IPv4 map-and-encaps would support > this, but IPv6/SEAL/IPv4 map-and-encaps would be much > better (and also much better than IPv6/IPv6). Are you suggesting that IPv4 be used as the backbone for encapsulated IPv6 packets? Wouldn't any self-respecting ISP providing IPv6-only services already have native links to the IPv6 DFZ? - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
