> >2) Globals and GUPIs - you don't want to rely on the stability of your > >allocated globals for your internal connectivity, so you roll out GUPI > >address space as well. GUPIs are used for your internal communications > >ie communications that doesn't travel across links that are part of the > >public Internet. > > You'd have to add three things to this to get to where I hope that > GUPI addresses will take us: > > - GUPI addresses may also be used to communicate over > private links with other GUPI-addressed networks.
Or for that matter, to communicate over private links with other networks that use globals. I don't see why it matters whether the other sites are using GUPIs or not - all that matters is that you have unique addresses for your site. GUPIs shouldn't be thought to have any special significance to apps, they're just a way to get a unique prefix when you don't have stable public Internet connectivity. The other thing that seems strange about this statement (to me anyway) is the idea that you use GUPIs for specific purposes or links. Ideally from my point-of-view you should have as few prefixes as possible and you should accept traffic for all of those prefixes on each of your links, and you should use packet filtering rather than prefix advertisement to control what kind of traffic you accept (and emit). That way, apps don't have to pick the "right prefix" in order to work. > - You may have different "levels" of GUPI addresses within > a single network... Some devices may use addresses > that are filtered at the department level, some > may be filtered at the corporate level, and > some may be filtered at the extranet level, for > example. absolutely. of course, you can do this with global prefixes also. > - Some companies may pay their ISPs to globally route their > GUPI addresses. I know that some people don't > want this to be possible, but I'm not sure why. > I agree that we should only advise this if we can > come up with an aggregable method for allocating > GUPI addresses. I don't know about "global routing". I can certainly imagine paying an ISP to route my GUPI-addressed traffic to specific locations, or perhaps throughout its network. I suppose I can also imagine paying my ISP to make arrangements with other ISPs to route my GUPI-addressed traffic in their networks. But I don't understand how my ISP can guarantee that every network in the world will choose to accept a reasonable amount of money for routing my GUPIs. It certainly seems important that GUPIs not be globally routable without a special arrangement. But I also wonder whether a market for routing GUPIs would not degrade Internet service for everyone by inflating the sizes of routing tables and increasing convergence times. I suspect that some constraints on use of GUPIs are necessary unless there are technical means of allowing dissimilar prefixes for topologically close networks to be aggregated for the purpose of routing computations and probably advertisements also. > We will need to do some work to document how other types of leaking > (DNS and routing protocol leaking, in particular) should also be > blocked at the same point as the traffic. However, this is pretty > commonly done for VPNs in IPv4, so there are some known solutions (route > filtering and split DNS). I don't think we should try to prevent leakage at any layer above a routing protocol. We certainly shouldn't depend on addresses not leaking. Sites can implement two-faced DNS if they wish (and deal with the operational problems that result) but in all cases app writers need to make sure that their apps do reasonable things when given addresses that they cannot reach. > However, it seems that people _will_ use filtering to create private > networks. The best we can do is try to provide a solution that > mitigates the damage. right. 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] --------------------------------------------------------------------
