> > > ... > > > 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.
I agree the analogy is imperfect for coordination of address spaces. however they have plenty of latitude regarding the nat mapping tables, and it's still a major pain to coordinate more than a small number of sites. > 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. strongly disagree. even though the use of NATs only directly affects those who use NATs, their effect is actually much broader - effectively preventing widespread deployment of any app that cannot deal with NATs. we have evidence that coordination of site-ids doesn't scale well, and at present the only alternative to having global addresses for private sites is v6 NAT. > > 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. nothing is free, strictly speaking. if you print a site-id on a label then the label costs a few cents. > > > 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? 37 bits might not be enough in which case we'd need a separate allocation for globally unique site locals. but if the normal way you get a site local is to buy a router, why would anybody need more site local prefixes than routers? > > 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. agreed, which is part of why 37 bits might not be quite enough. still, allocating 11 bits for vendors would give each vendor 67 million numbers to assign, and that's assuming that every vendor got the same size allocation. or you could have more vendor IDs and give each one fewer addresses per allocation chunk, which would use the space more efficiently. I see no reason why we shouldn't be able to get at least 2**32 distinct site IDs from 37 bits of address space. > > 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? the same way you know that an ethernet address is unique. > > 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. yep, and it's both cheap and transparent. works beautifully. > Another poor analogy > because if we were running a global ethernet bridged network, who said anything about running a global ethernet bridged network, or anything on that scale? surely you don't expect every private network in the world to establish a bilateral interconnection with every other one? that's what the public network is for. > > 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. as I understand it, sheer lack of address space isn't usually the problem because they're typically not using one-to-one mapping anyway. > > 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. tell that to the apps that have to live in multiple networks at once. > > 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. then figure out how to give every network in the world a global address. which it seems is what we're both trying to do, though we have different ideas of how to go about it. I don't have any fundamental objection to PI addresses, but I acknowledge there are problems to be solved, and I wish you the best in your efforts to solve them. OTOH you seem to have fundamental objections to globally unique site prefixes even though you reject the proffered solutions out of hand without really considering them. Frankly I think that's counterproductive. > 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. no I'm arguing that every network, private or public, should have globally unique addresses available to it, and every host on such a network should be capable of using those addresses, so that apps don't have to deal with limited-scope or ambiguous addresses at all. > 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. not true, at least not so long as addresses have to be obtained from an ISP. 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] --------------------------------------------------------------------
