On Thu, Mar 27, 2003 at 12:01:44AM +0100, Brian E Carpenter wrote: > > Also if you have any hosts that support 6to4, which is not the model > described in RFC3056 but is shipped in at least one o/s, strange things > may happen.
Indeed. But my (perhaps not well written) comment was based on Mike's requirement to have a multi-site community network, e.g. a number of DSL or dialup homes (who should by current RIR guidelines receive site /48's from their upstream providers) who also participate in a routed mesh WLAN network across a city (i.e. homes with 802.11b). The WLAN infrastructure needs its own address space, but site locals are desirable for the home networks connected via WLAN in the event that any home is disconnected. Also, transmission across the WLAN is likely to give better performance than routing out and back in through the DSL or dialup. If such homes get /48's, then the community mesh network needs more than a /48, which discounts 6to4 as a "site" solution, esp. if the infrastructure were v6-only (which to be fair is not yet a likely reality). In such a case there is no single upstream provider (the homes may subscribe to any service provider). Of course some community networks may only have one (fatter) upstream. But the more interesting ones allow you to select from multiple providers (e.g. open.net in Sweden) where you use site-locals to access community content until you authenticate to an external provider, at which point you receive global address(es). The current answer seems to be: a) Pick someone else's global /32 and use that b) Pick some other random /32 prefix c) Pay $$$ to get LIR status to get a global /32 d) Request as many GUSL-based /48's as are needed e) Use geo-addresses f) Use fec0 space anyway Option c) is out as it costs real $$$. Options d) and e) are not defined yet. So we might as well accept that people will use fec0, but simply not give that prefix any special scope treatment. Is it the scope rules that cause the problems, or the definition of an available prefix? As Michel says, we've been here with IPv4 before. At least with v6, market forces should lead people away from NAT (if they want the nice new v6 apps). I'm happy to see the back of site-locals, so long as current (and most importantly) future network requirements can be met without them, and at the same cost as site locals (free). Tim -------------------------------------------------------------------- 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] --------------------------------------------------------------------
