> Well any app that is generating 'spam' should be restrained.... > > You missed the point of what I was saying. Within the context of a > private network of one or more sites, there should be no ambiguity > because the local manager is in control of the proposed site-id bits.
no, because there is more than one site, and there is more than one local manager, and given enough private interconnections the chances of a conflict start to become significant. (in other words, it's not reasonable to assume that a private network is well-bounded or that it doesn't interconnect with other networks that do connect to the public network. and even if those networks don't provide transit to the between the public network and private network there may be apps that have to deal with addresses from both types of networks) if you have enough bits for the site-id you can make the probability of a conflict approach zero *provided* the site bits are randomly chosen. but the easiest way to avoid conflicts is to make the site-id globally unique, and there's no good reason to not do so. now if we really get PI space set up in such a way that any site can get a unique chunk of PI space whether or not it is connected to any public network, that would remove the need for unique SL prefixes, and that would be fine with me. but while I'm glad people are working on proposals to do that, I'm not holding my breath waiting for it to happen. if we end up with both unique SL addresses and PI addresses, that's not a horrible thing. but SL addresses without a site-id just cause more harm than good, and they really need to be eliminated in favor of unique SL addresses, unique PI addresses, or both. Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
