Keith Moore wrote: > > ... > > 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.
That is a poor analogy because they really haven't had enough space to work with. Also, they are the ones motivated to make the interconnect work, so there is in fact every reason to make them responsible for it rather than burdening a public resource for private gain. > > > 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.) and that implementation mechanism is not free. > > > 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. There are only 37 bits to work with, and what is to keep everyone on the planet from asking for 1000? > > 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. As soon as you introduce the inefficiency of aggregates, the potential number of sites goes down. > > try not to GC the addresses at all. > or if necessary, 'lease' them for long periods of time. how do you know it is unique if there is no GC, even if it is broken into multiple database segments? > > > > 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. You pay for it with every device you purchase. Another poor analogy because if we were running a global ethernet bridged network, there would in fact need to be a very large database of address to contact mapping for any hope of operational debugging support. With IPv4 we reduce that database by aggregating collections of addresses under a single contact, and that system still struggles to maintain accurate data. > > 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. and your argument that a group of sites can't coordinate is unconvincing. If we had set aside 32 /8's and it wasn't working, then I might buy it. > > > > > 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, By definition a private network is bounded, just ask the administrator where the boundaries are. If they don't know where the boundaries of their network are they are open to much bigger problems than a few apps not working. > and even when the network is bounded as far as routers are concerned, > an app may have to communicate with peers in several networks. If an app needs to leave the bounds of a private network, it should be using global addresses. If you are arguing that a multiparty app with multiple participants on both sides of the site boundary should be able to pass around both SL & Global as explicit addresses, explain why. The only reason I see where it might need to is if one of the participants has only a SL prefix. If that is the case, that node has clearly been put in a region where access to, and interactions with, nodes in the global space are administratively intended to not work. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
