> Margaret Wasserman wrote: > Do you really think that it is realistic to just tell > everyone to use provider-assigned addresses throughout > their network?
No. Scores won't buy it. Let's not forget that one of the reasons behind the considerable success of NAT, despite its huge annoyances, it because NAT does provide some of the PI perks. PA is good for dial-up users and home/soho setups. Bigger, you find NAT, because for many the no-sweat ISP switch is worth more than the NAT-induced problems. In my experience, the number one reason for going to RFC1918/NAT is an ISP change. The ISP pulls out of a market or tanks, the customer looks at my proposal for renumbering, chokes at the bottom line, and says "make sure we don't have to go through this again next time the ISP bellies up". Welcome to NAT. Having two of the tier-1 ISPs in bankruptcy does not help this feeling. > We've been getting feedback from network administrators that > they need a form of local addressing that allows their > internal numbering, firewall configuration, etc. to be > independent of their ISP-provided addresses. Network administrators want three things: 1. Local, private addresses that do not communicate outside of their site. Site-locals are perfect for this, if they are not limited to disconnected sites. 2. Unique addresses that do not need public Internet access but do need to communicate with selected external sites (example customer/supplier VPN). This is GUPI. 3. Global network layer PI identifiers. Although this is not directly linked to the multihoming issue, it is likely that a scalable multihoming solution would provide it. I do not envision a large-scale deployment of IPv6 without providing all three. Also, it would be a hell of a good idea if 2. could migrate to 3. > It is my belief that if we ignore this problem, and simply > limit site-locals to disconnected networks (a la RFC 1918 > addresses), then IPv6 NAT will arise to allow sites to > separate internal addressing from external addressing. Agreed. And we should not underestimate the danger of this, as there is a lot of working v4 NAT code out there and transforming v4 NAT code into v6 NAT code is a lot less work that writing NAT from scratch 5 years ago. Most of the ALGs issues have been sorted out already. > What we really need is a better way to solve this problem, > one that doesn't have the problems of site-local addresses. > And, that's why we're discussing GUPI addresses. Agreed. Unfortunately, one of the main issues with GUPI addresses is managing the risk they end up being a mess in the global routing table, � la IPv4 swamp. So far, the lack of a multihoming solution has been a strong enough disincentive to kill GUPI attempts in the egg before they were even born. Any GUPI proposal will have to address this. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
