> > we need to get rid of site-locals. merely renaming them as > > private use addresses wouldn't solve any of their problems. > > there's no advantage to moving to IPv6 if it repeats the RFC > > 1918 mistake. > Hyperbole does not serve either the community, or one's own > position, well in this situation or others like it. John, If I understand what you are calling hyperbole I would instead call it the 10,000 meter view. That is, I don't see a significant market for IPv6 if it doesn't support applications that cannot be run on NATted IPv4. Yes, there may still be some small advantage of IPv6 for some groups of users if this doesn't happen, but not for the Internet community as a whole. So "no advantage" can be taken as an exaggeration, but the intent was to avoid getting bogged down in detail about exactly what minor advantages there might be and why they're unlikely to create enough incentive for any widespread adoption of IPv6. And no, I don't think that reducing the number of NATs by 25-50% would create a significant advantage to moving to IPv6. In order to create a significant advantage, there need to be so few NATs in IPv6 that application developers can write applications that will fail in the presence of NATs without fear of losing a significant number of customers. I agree that there's a requirement for PI addresses, and perhaps, for PI addresses that don't require RIR allocation. Various solutions have been proposed, but we seem to be unable to evaluate them or choose between them because we're too busy arguing about whether the v6 network should be saddled with the baggage from v4. The discussion about SL also seems to be couched in those terms, as well as being confused by efforts to conflate different notions of scope that are better understood separately. IMHO, those who think that hosts or apps should have to bear the burden of picking which address or interface to use in order to get packets to their destination need to explain (a) where the hosts or apps get the information necessary to make those choices in a reliable and timely fashion, and probably (b) how to provide a usable endpoint identifier under those conditions that can be passed between hosts at arbitrary locations. Until then, I'm not convinced that the v6 assumptions about multihoming are workable. Which further leads me to conclude that we still haven't figured out a way to make IP routing scale in a practical sense. Keith