Been busy with other stuff, but I'll respond to a few points briefly. On Tue, 26 Aug 2003, Michel Py wrote: > >> Doubly irrelevant to the discussion: first, you can't ask > >> every network to become a LIR; second, the need for public > >> addresses and local addresses is totally different, so > >> even if one enterprise has become a LIR to obtain public > >> addresses it does not remove the need for private ones. > > > Sure, but there are also other ways to obtain addresses. > > Really? Would you care naming one available today?
a) talk to your ISP (or one of its upstreams), which his hopefully a LIR, or b) talk to any LIR, and pay him e.g. 100$/mo. He'll gladly give you address space even though you don't want physical connectivity at all. > > My (and others) goal is to show that the use of local > > addressing is not the right approach in many cases, and show > > some alternative means to achieve the same ends. > > It does not work that way. First, network administrators for the most > part don't read this. Second, you have not been an enterprise network > administrator for any significant time so they're not going to listen to > you anyway. Third, the reasons enterprise network administrators make > decisions are for a significant part based on experience; in other words > the reason to use local addresses is either because some day one did not > use them and got shot, or because some day one did use then and it saved > one's butt so one keeps using them. What you have is untested theories > about network design, what they have is years of experience that built a > sense of what works and what does not. Well, I don't know how network managers react, but when I've been a network manager here, we've certainly never used private addresses in our network except in a few cases (from the top of my head): - certain routers peer with each other in access networks (using private ASN's) using private-space addresses for iBGP sessions (assigned on additional loopback interfaces). At first, this was not so, but we had to implement some visibility restrictions for IP addresses used for iBGP because of a bug/"feature" in a major router vendor's BGP implementation *). We could have very well used routable, filtered at the edge of the access network instead. - one inexperienced admin wanted to set up an out-of-band, privately addressed management plane for controlling a few firewalls. A bad idea, so I disabused him of it. - private addresses are being used in our separate backup/restore and NFS infrastructures (most hosts connected to it use separate network interfaces etc.). This has generated some trouble, and could be done using different addressing model as well. Trying to summarize what people think they need local addressing for in enterprise scope (intermittent connectivity etc. is another beast altogether). Some would like it to have local communications in a shared infrastructure. A very bad idea. Some others would like it for separate infrastructures (like out-of-band management, NFS run on big servers, backup/restore systems systems run on larger servers etc.). The latter is more easily justifiable, but I there are no fundamental gains to be had from that approach AFAICS. Quite the contrary. *) This is already offtopic, but I'll state it briefly. Further discussion, if any, off-list. iBGP advertises the loopback address A.B.C.D/32 with next-hop A.B.C.D/32. A.B.C.D is directly inaccessible (so there is no IGP route). However, the packets go and traverse through the eBGP default route, and when they learn A.B.C.D/32 through it, start start to use it, but then the route becomes unavailable and starts oscillating. Possible fixes? Enable IGP synchronization (a non-option for most), make a check that the next-hops of iBGP routes must exist in IGP (either OSPF/IS-IS or iBGP; eBGP would be invalid **) -- note that one must disregard A.B.C.D/32 w/ next-hop A.B.C.D/32 (to avoid recursion) for this process, or disallow going through eBGP routes to reach an iBGP peer. **) RFC1771, section 9.1.2, second last paragraph on IGP. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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] --------------------------------------------------------------------
