kre, >> Tony and I are proposing schemes that are aggregatable and >> that are not tied to a provider.
> kre wrote: > Both those schemes are geographic based addresses - these aggregate > if and only if one assumes that areas that are geographically close > are also topologically close. This is absolutely untrue. I will let Tony defend his own, but for the two different methods that ipv6mh is working on, there is no relation whatsoever between the network/fiber plant topology and the geographical aggregation. > They're provider independent only of there are multiple providers > that have agreed to cooperate with each other and share the > prefix (essentially routing packets to each other when they arrive > at the "wrong" place). This is another wrong assumption. We know that asking ISPs to advertise a geographical aggregate that contains competitor's addresses is not going to fly. I would not do it myself. The solutions that we are developing do _not_ require transporting competitor's traffic. > While that is entirely possible to assume might happen in some > high density usage parts of the world, where multiple providers > can all exist and make a profit, in much of the world, the simply > aren't enough active users to support the infrastructure for > multiple providers. We do not require any local infrastructure. > Anyone would always be free to connect to a different provider, > by simply connecting to a more distant location of course - but > then their address would not (could not if any aggregation at all > is to be achieved) be based upon their geography, but the > provider's instead. That is, to change providers an address > change is likely to be required for many (perhaps most) and for > those it isn't, the provider choice will be limited to those who > have managed to join the local provider club. True, but what if joining the local provider club is free? You would have a point if being present at some kind of IX was required, but it's not. > On the other issue ... anyone can (attempt to) pay any ISP, or set > of ISPs to carry any address. The rish is certainly no greater of > that happening with a SL address with a site-id embedded, than it is > for a global address allocated by a different provider, or a > geographic address from some other region. A valid point. Please note that we are not claiming that geographical addresses alone will solve all of the problems at once. > If anything, the risk is less with SL addresses, as they can be > clearly labelled "for local use only", lowering the chances that > people will ever decide they would like to interpret them as global > addresses (all of these things are just numbers, so perceptions, > and what the ISPs will agree to do are all that matters anyway). > Global addresses are expected to be globally visible, and there's > no reason at all to assume that people won't go to a competitor > ISP and say "I will connect to you, and pay you all these $'s if > you will agree to advertise the prefix I have already been > allocated this other way" True enough. However, you forgot two important things: 1. If we make SLs with site IDs globally unique, there might be no assignement (or the assignement might be automatically granted by the addressing architecture, say a 37-bot hash of the MAC address, or whatever). With the geographic scheme we are designing, there would still be the need to go to a RIR and register a block, so we might still decide that someone with a dial-up 28.8k modem does not qualify for a portable, globally unique /48 block. 2. SLs do would not have a supporting protocol if used globally (how could there be one, if they are not supposed to be used that way). The way I see the geographical addresses is a support of the multihoming protocol. And if there is a protocol, there can be safeties and policy enforcement features built in. > (and even say to ISPs, "I will connect > to you, and you allocate me > an address, but you agree that once allocated you can never reclaim > the address, no matter whether I stop paying you or not"). Not very realistic, IMHO. First, no ISP would put that in writing. The, what happens if the ISP bellies up? Michel. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
