> >> Michel Py wrote: > >> Here's the dilemma: if the scope of GUPI is global, how > >> could you guarantee that people won't pay their ISPs to > >> leak the GUPI address in the defaultless routing table? > > > Keith Moore wrote: > > If people don't want their addresses to be publically > > routable, why would they pay their ISPs to route them? > > My point precisely: > GUSL -> Scope is site-local -> no public routing. > GUPI -> Scope is global -> if there is public routing > this solves the multihoming issue (unfortunately, > by exploding the routing table.)
Not necessarily. There appear to be solutions for global routing of distinct prefixes which do not explode the routing table, but they don't solve multihoming either. > >> The big difference is that with GUSL we would have > >> extended the scope to friendly sites, not to global. > >> The risk of GUSL ending up global PI could be managed. > > > I don't see how this is changed by a decision to not > > use FEC0::/10 for globally unique addresses. > > Because the scope of this new block would be global, if have not misread > you (instead of local). What you seem to be trying to do is to say that since we don't currently know how to scale global routing of non-aggregatable prefixes, we need an architectural limitation to prevent it. I don't believe that it's appropriate to wire limitations of current routing technology into the addressing architecture. > > But there still seems to be an inherent conflict between > > those who are demanding non-routable addresses (is anyone > > else demanding this?) and those who want GUPIs to be > > routable. If there's really sufficient demand for both > > maybe we need separate blocks. > > Since London I have tried to push a multihoming draft that implements > local PI as identifiers. I've heard "It's based on PI, I won't even read > it" and "PI sucks, don't waste your time". Well, since Atlanta there is evidence of considerable interest in PI identifiers. So maybe people are coming around... > What makes you think that GUPI would be different? You don't even have > the multihoming carrot. Don't get me wrong: I'm not against GUPI on the > principle, just pointing out that it has been stalled in multi6 forever. multi6 is working on different things. If it turns out that they find a way to globally route GUPIs, that would be great. But we don't need to solve the global routing problem to make globally scoped PI addresses useful. > In other words: I'm not saying we should not work on it because it's > bad, but because it's a waste of time today. Actually I think the lack of GUPIs is one of the biggest things blocking progress of this group - it's forcing people to try to make SLs do things that they simply cannot do well given the assumptions that are already wired into the architecture and into code. 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] --------------------------------------------------------------------
