> > I think this WG needs to define GUPIs - because that seems like the best > > way to take the pressure off of SLs to be misused. however I don't think > > we should try to make them globally routable, at least not now. > > I don't really agree that this is what we should be doing. > > I think: > - if we specify global-scope GUPI's they will also be used when regular > global-scope addresses would be better (and we should encourage PA > addresses, because they actually _work_); ie. they will cause trouble and > may eventually result in prefix/address translation (NAT-like) problems.
mumble. all we can do is give people good tools, explain how they were intended to be used, and hope they use them in an optimal fashion. right now we are in a situation where SLs will be used for situations where they are not good tools. the only way to solve this problem is to give people better tools, and GUPIs seem to be a good fit. yes, some people will probably try to use GUPIs where PA globals would be a better choice. eventually, they'll learn. they'll have to renumber to fix that problem, but it won't be more difficult than any other kind of IPv6 renumbering, and we have to solve that problem anyway. > - if we instead specify site-local, near-unique addresses, folks still > treat them as site-locals; they are used less than GUPI's would be, in > site-local contexts only. Near-uniqueness removes the problems with > ambiguity of site-locals. yes, but that's not the only problem with site-locals. another problem is that it's widely believed that they are some kind of security mechanism. another problem is that it's widely believed that hosts and applications should treat them differently than other addresses, either by filtering them or by preferring them over other addresses. in other words, there are lots of dubious assumptions about site-locals that are more easily and more effectively fixed by discouraging many uses of site-locals, and providing an alternative for the valid use cases, than by trying to change people's mindsets about what site-locals means. > - I think it's better to deal with reality (provider assigned addresses) > than try to escape it (provider independent addresses), even though how > enticing it could be... "reality" is subjective. I think it's fair to say that we know how to make PA addresses routable on a large scale, and we don't know how to make PI addresses routable on a large scale. On the other hand, I think it's also fair to say that PA addresses don't do everything that people need - they don't support multi-provider multihoming, and they don't support networks that aren't connected directly to the global internet. So PA addresses are desirable but not sufficient. > Following my thinking, site-locals could of course be used as an aid for > e.g. renumbering or intermittently connected sites, but that should be > better than having delusions that using global-scope addresses there would > somehow make such addresses "global" or "globally usable". I guess we are concerned about different anticipated delusions. I'm much more concerned about the delusions that already seem to exist about the applicability of site-locals than about the delusions that might exist about the applicability of PI globals. I do think that an addressing architecture that simplifies decision-making would minimize the potential for delusions. From that perspective, a simple table is quite attractive: case | recommendation --------------------------------+----------------------- network connected to the | PA global addresses public internet | | network not connected to the | PI global addresses public internet, but | connected to other IP networks | via private arrangements | | isolated stable network | PI global addresses or | site-local addresses | isolated ad hoc network | site-local addresses 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] --------------------------------------------------------------------