On Mon, 25 Aug 2003, Michel Py wrote: > > Pekka Savola wrote: > > What I'm trying to say is that we need to first figure out > > where we need local-use applications -- and, as an interim > > feature, maybe reword the current draft so that it's > > apparent which current perceived local-use scenarios > > require specific requirements. > > This appears to me the opposite of what is generally done within the > IETF. First we write requirements then we look at specific scenarios, > not the opposite.
My point exactly! Why are we writing requirements for _local addressing_, and not writing requirements to solve the problems which people perceive exist in IPv6 after the elimination of site-locals?!!?!? > >> which is one of the reasons that eventually led to RFC1597. > >> What makes you believe that the reasons they did it in the > >> past do not exist anymore? > > > And what problems has this caused that are really, really > > problematic? > > NAT, in the first place. Please be a bit more specific on how that came to be. Do you mean that folks who hijacked the address space deployed NAT to be able to continue using their hijacked space inside their network but do one-to-one conversion at the border? > > On the other side, I fail to see the need to hijack a > > prefix for your running system. IPv6 addresses are quite > > obtainable nowadays if you're an equivalent of LIR. > > 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. So, what you're really saying that folks would hijack prefixes to be used internally (instead of trying to use them externally). I wonder if that was the case of prefix hijacking by-and-then. Sites could very well get another /48 for internal-only connections, and /48 for public ones, I guess. Easy to filter at the edges, doesn't need to be routed, etc. Shouldn't be a huge problem in getting through RIR policies. > > In addition, compared to the situation back in 1994 (and > > earlier), people actually use Routing Registries to check > > advertisements. You really cannot assume that you could > > hijack a prefix and have it work in the Internet. > > I have live examples that use NAT for that purpose and some other people > have contributed the same here. > > You did not answer the question. The question is not why network > administrators are wrong to use local addresses. Wrong or not, and > whether you like it or not, they have, do and will use them. Putting > your head in the sand or stating that there are no reasons to use local > addressing is not going to change it. > > There are extremely large numbers of networks that currently use local > addressing; RFC1918 is not what created this situation: to the contrary > it is a by-product of their widespread use and created well-known > prefixes for them. > > What makes you thing that the requirements of all these networks have > changed? Given time, bogus requirements could be shown to be bogus. Perhaps SoBig and friends have enlightened some network managers to the fact that private addressing helps you not at all. I do not see the need to repeat IPv4's mistakes in IPv6. That's why we advocate dual-stack deployment. If you want to keep the broken designs, keep those IPv4-only. 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. If, in the end, the users wish to shoot them in the foot, we can't prevent that, but via these procedures I'd hope it's the 1% who do the shooting, not 99%. -- 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] --------------------------------------------------------------------
