> Keith Moore wrote: > > ... > > (in other words, it's not reasonable to assume that a private network > > is well-bounded > > Like it or not, routing protocols actually do require that the > boundaries of a network be well defined.
but not all routers share the same view. and in general applications aren't aware of such views at all. > > or that it doesn't interconnect with other networks > > that do connect to the public network. > > As I said, all they have to do is coordinate the space. this is more difficult than you make it sound. private networks have found it difficult to coordinate IPv4 private address space, or even to coordinate the NAT mappings between their addresses spaces. and there's no good reason to require them to do so. > While it might > be nice if they didn't have to worry about any possibility of > collisions, their private use of space does not justify a public > registry. the fact that the same apps can interact with peers on both private and public IP networks does justify it. (though I'd be happy if we can find a way to prefixes unique without such a registry. the best way I can find to do that is to allow a prefix to be derived from something like a MAC address of a network device - which is fine as long as you always keep that network device... problem is that makes the prefixes something like /64. but unique prefixes are the essential feature, the registry is just an implementaiton mechanism.) > Even if we created a public registry, who would pay for its > maintenance, and what would be the rules for acquiring a site-id? We > already have public registries struggling with these issues just to keep > a relatively small number of SPs happy. How would that scale up to > handle every possible side-id request, and garbage collection as the > original requestor goes away? make sure there are plenty of site-ids available. delegate blocks of site-ids to parties in a good position to make them available to customers - say router vendors. let them ship one attached to each router, with a bar code label. allow people to obtain them from other parties (DNS registrars, RIRs, etc) as a backup mechanism. try not to GC the addresses at all. or if necessary, 'lease' them for long periods of time. > > 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. > > Yes there is, and it has everything to do with managing a large global > database, and nothing to do with bit patterns as seen by an app. where is the large global database of Ethernet MAC addresses? that system of assigning unique IDs seems to have worked reasonably well without an expensive infrastructure. so I think your concerns about management are unfounded. > > 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. > > The focus of my PI draft has been on multi-homing, but it could be > expanded to cover the case of the globally unique range for a > disconnected set of sites. This is not because I prefer it over making > SL unique from a bit-pattern perspective, but from the operational > perspective a global database for SL can't scale. again I don't have a problem with PI addresses if you can solve the problems associated with them, but it seems premature to exclude globally unique SLs until you'e convinced people you can solve the ambiguous address problem in a better way. and your argument that the global site-id space "can't scale" is so far unconvincing. > > 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. > > SL addresses without a globally unique site-id are only a problem if > people expect them to work outside the context of a private network. private networks aren't always bounded like you seem to think they are, and even when the network is bounded as far as routers are concerned, an app may have to communicate with peers in several networks. 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] --------------------------------------------------------------------
