Re: A simple question

Hi,

Daniel Senie wrote:
> Example of usage: I use RFC 1918 space for private networks within 
> server farms. There's no connection to the public network from this 
> private segment. Servers connect to both public and private networks. 
> Backups, NFS mounts, SNMP and SQL data flows over the private network. 
> The isolated network segment keeps traffic off the public network for 
> performance reasons.
This has become an acceptable use of RFC 1918 addresses.  On the other 
hand, there is no need to support this sort of use in the v6 
architecture.  The address space is simply too vast for people to have 
to economize like this.
> All the world of private addressing is not NAT, regardless of how many 
> times people say it is.
My major concern that does drive NAT is the expressed desire on the IPng 
list to isolate sites from having to renumber.  That use of SLs requires 
NAT or proxy.  Rob may call it crazy, but the demand is there right now.
> I am saddened by the fact that Tony's simple question could not be 
> addressed. Site local addressing in IPv6 is a concept which has been 
> mentioned in RFC 1884, 2373 and 3513, the progression of Proposed 
> Standards. This is a string of documents dating back to 1995. For eight 
> years this concept was apparently considered a good thing. The 
> discussion on the mailing lists makes it sound like site-local 
> addressing is a new idea. I'd like to know why it's taken eight years 
> for folks to decide it's bad. Is it that folks are just now implementing 
> IPv6? Is it because the documents these eight years never made the 
> concept clear, and now it appears too hard to implement? In all those 
> years, has no vendor implemented site local? Are there any other 
> features we should reconsider as long as we're ripping the documents open?
Quite simply it is something we seem to have forgotten about: learning 
from operational experience.  Since 1995 the use of private address 
space has changed, as has been said.  Also, I don't think people fully 
understood the ramifications of SLs.  I certainly didn't, initially.  We 
also learned that using EUI-64s as end identifiers has certain privacy 
considerations, so this is not a first.  I think we do have to take some 
care when making changes to the addressing architecture.  If the 
decision of the group holds, it seems to me that those of us who voted 
"YES" have the burden to now provide an alternative that addresses the 
real requirements that SLs attempt to tackle.
> It is not unprecedented to change or remove a feature as a document 
> advances through the standards track. Such changes, however, can have 
> significant impact on already-implemented and deployed solutions. Such 
> matters should be considered carefully in that light. Perhaps removal of 
> features should receive substantially more scrutiny after publication on 
> the standards track.
I agree.  The vote was for deprecation.  That means we need to deprecate 
in favor of something better.
Happy holidays,

Eliot