Brian, > Brian E Carpenter wrote: > Access control lists in routers were in use for > this years before RFC 1597. Preventing unwanted > access has never been a valid argument for private > addresses and never will be.
I have to disagree with this. There are some legitimate cases of using private addresses for security purposes in "defense in depth" scenarios that Richard Draves and I described earlier. This creates demand for them. However, the issue has nothing to do with technical reasons and everything to do with this organization designing protocols without paying attention to customer needs and getting us into the same circle one more time. Private addresses != NAT. Perception == reality. Private addresses == security. Network administrators want security. Network administrators want private addresses. Ignoring this fact will lead us in network administrators hijacking prefixes again; then some vendor will produce a de-facto hack for them, likely the hack will fall under the umbrella of one of these mighty corporations that according to popular belief produce junk, then everyone will be complaining about big mighty corporations producing proprietary junk, but we will produce an RFC to rubber stamp the de-facto junk and the loop will be closed. Please, not one more time. There is a need for private addresses, if we don't provide a solution the market will and we're not going to be happy with it. As Margaret pointed out, > Margaret Wasserman wrote: > Unfortunately, there is another reason why enterprises > use NAT that has not been addressed in IPv6: provider > independence. Although one of the big driving forces behind NAT is the lack of PI addresses, there is an aggravating factor which is the ambiguity of private addresses, which eventually leads to internal NAT when sites merge. It is allowed to hope that this factor alone would not trigger NAT happening if the PI issue was solved, but why take a chance? We need private addresses, and preferably unique ones. In order to achieve this we need some kind of architectural limitation to replace the fact that ambiguity guaranteed non-routability of private addresses. Keep in mind that we don't need non-routability of private addresses for security reasons, we need it to ensure there is no routing table explosion. Site-locals provide this architectural limitation. What do we have to replace it? Nothing. People hijacking prefixes will re-introduce most of the problems that site-locals have, putting them under the rug does not solve them. I understand that there are problems with site-locals, but deprecating them should not introduce new issues. Let's be careful not to have a cure that is worse than the disease. 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] --------------------------------------------------------------------
