Robert Elz wrote: > > Date: Tue, 10 Jun 2003 11:49:35 +0200 > From: Brian E Carpenter <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > > | If one could go and get a prefix under 2000::/3 today that was not tied > | to an ISP, that would be just fine. > > So, you mean there's a need to have address stability inside the VPN?
Yes, but more than that, inside a shifting population of company networks that are constantly joining and leaving virtual organizations. You can imagine the gymnastics of this unless there is a reasonably high probability that there will be no collision between prefixes. > > That's fine - but I'd like to see that made clear whenever this issue > is raised. I haven't had anything to do with large VPNs, and with > that lack of experience, I can't see any particular reason why address > stability is any more required there than the internet at large. > That is, I always thought a VPN was more about access control, rather > than anything else. Traditionally, yes, but traditionally we haven't viewed distributed computing as a resource purchased on demand. This is changing, and the work-arounds for Net 10 are becoming onerous. > > | I see is a lightweight way to get a PI prefix that isn't ambiguous. > > For stability, you'd want a prefix that doesn't conflict with any of > the prefixes used by the members of the VPN. For that, whoever is > primarily responsible (someone must be doing access control policy) > can just collect all prefixes in use (ignoring normal global ones as > the first few bits will serve to eliminate those) and generate a new > number that is different than everything connected (the list of > "connected" can include everyone who may someday potentially be > permitted to be a part). Once allocated the number can be advertised > (as in, on a web page) and anyone who ever feels they might like to > ever become part of that VPN could avoid it. > > There's no need for a registry for this. That doesn't solve the N**2 problem where any customer may want to join any VPN at any time. We don't want everybody to start numbering at 1. > Of course, Benny's suggestion should also work for this - anyone who > wants runs a registry, most likely with some particular target audience > in mind. One of those would perhaps be "anyone involved in the auto > industry in any way", another perhaps "airlines" - then after inventing > your own prefix, you go register it with whatever registries seem like > they may keep your number unique, and if there's a conflict in any, > start again. So a tyre maker might register with both an auto and an > airlines registry, whereas a maker of car radios probably only (or those) > the auto registry (but perhaps also an electronics registry). That's a lot of complexity compared with either a generic pseudo-random algorithm or a global registry. (I can't see a logical objection to multiple registries, if IANA gives them each a prefix, but I don't see a benefit either.) > > That way, it is very likely that anyone (who had bothered to register) > in any likely field would have a number distinct from everyone else, > without expecting or requiring me, at my house, to bother registering > anything with anyone (as I personally don't want a VPN like this, and > don't care who else is using the same non-routable numbers as I use). But I don't believe that in the future world of computing as a utility service, we can assume that customers and service providers are neatly segmented into fields of application. > Both methods avoid the "this is globally unique" fiction, and hence > make it very unlikely that someone will later attempt to depend upon > that (as in the "everyone we know has a number that is unique"). Well, somebody will depend on it whatever we write, but you have a point, which is why I've always said that I'd settle for "probably unique". Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
