I'm trying to understand this whole GUPI prefix business. I have to say that I'm fairly confused, and therefore this attempt to summarize and envision the case. Please correct wherever I've mistaken.
The GUPI proposal seems to have grown from the concerns regarding site locals. (I have to confess that I still do not quite understand why some people think that site locals are that bad; I guess there have been too many messages. I am still looking for the pro and cons drafts Margaret(?) suggested/asked for a few hundred messages back. Anyway, that's not the point here.) The GUPI prefixes seem to have a lot of desirable properties. Leaking GUPI addresses are less likely to cause confusion than leaking SL addresses. Site merger is easier with GUPI prefixes than without. GUPI prefixes allow limited inter-site communication through direct peering or tunneling. Statistically unique GUPI prefixes would be easy to generate. etc. Some people seem to think that GUPIs would reduce the need for IPv6 NAT. Maybe so, maybe not. More below. Requiring mandatory registration for GUPIs may make it easier to track down people leaking GUPI routes, but not necessarily so. But at least that would give us a scape goat, someone to yell at if a prefix is leaked. OTOH, mandatory registration would make it very hard to use them at non-connected sites. Now, suppose for a moment that we do have such GUPI prefixes. That is, prefixes that are (statistically) globally unique, provider independent, free, forever valid requiring never renumbering, and easy to generate even for non-connected sites. I guess almost everyone would start using them. At least I would personally, just for my personal VPN between my office and home. Thus, there would be millions of these prefixes in use. With some more invention, such as using them for PANs or semi-stable ad hoc networks, there would be billions of dynamic sites using these prefixes. From a site multi-homing (multi6) perspective, it might become again a (not so) good idea to perform prefix translation at the site exit routers. If you configure your network so that all hosts defend the same IID with the GUPI prefix and the global prefixes, thereby making IIDs unique within the site, you could fairly safely translate a GUPI prefix in source addresses into your global prefix for outgoing packets and vice versa for incoming packets. MULTI6 solved :-) From a mobile networks (nemo) perspective, you could use your GUPIs inside your mobile network (airplane, car), and again perform prefix translation at the site exit router. NEMO solved :-) (For those you missed the irony: I know pretty well that prefix translation would not solve the problems multi6 or nemo are addressing. I just want to point out that GUPIs might make people to consider prefix translation more seriously, since it would look "safer" with GUPIs.) More seriously, there would be a tendency to consider GUPI addresses as immutable identifiers for hosts, making the aggretable global PA addresses mere locators. Thus, it might form a step towards an architecture where identifiers and locators are separated. Now, honestly, I do not know if that would be a good step or not. We just have to understand that there would be a strong temptation to view the situation so. Furthermore, I guess that many people might just start using the GUPI addresses so, without thinking too much about the architectural consequences. --Pekka Nikander -------------------------------------------------------------------- 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] --------------------------------------------------------------------
