Michel, If we simply say these NEVER leave the site then all is fine. Thats the bottom line.
/jim > -----Original Message----- > From: Michel Py [mailto:[EMAIL PROTECTED] > Sent: Monday, August 04, 2003 1:47 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: site-local observations from the outside > > > Todd, > > > Todd T. Fries wrote: > > Either you have link-local addresses, or you have > > global routable addresses. > > From a transit provider point of view this is true, but not > for the enterprise. There are lots of large networks that > require private addresses and use RFC1918 today. Examples > that have been discussed before are a large cruise ship and > utility companies. Part of the requirements is that private > addresses must not be routed on the public Internet. > > > > Any attempt at providing something that is site local > suggests to me > > that you open the doors wide for something like NAT, which > of course > > none of us wants. > > There is some truth to this, but in the end avoiding NAT will > not be achieved by not providing site-local addresses, as > they are not required per say; people that need them will > simply hijack an unused block in the middle of nowhere in the > IPv6 address space, like they did for IPv4 pre > RFC1597/RFC1918. A good hijack candidate is 2002:RFC:1918, > for example. The only way to avoid NAT is to provide what NAT > does, which is portable, globally unique, globally routable > addresses, which we don't have today. > > > > There is enough address space in the global table, > > Wrong. There is enough address space today, but the global > routing table cannot handle billions of entries, at least not > with BGP4+. It's not a matter of memory, it's a matter of stability. > > > > why can we not have some sort of free reservation system > > (the free tunnel brokers would suggest it is economically > > feasible) for sites that want local addresses but do not intend on > > globally routing them. > > jj has proposed something like this not too long ago. A draft soon? > > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
