> | but it depends to some degree on how LL is pitched to the public. > > Yes, exactly - and one of its planned uses (right from day 1) was to > support "dentist office" networks - perhaps more likely these days > as "IETF attendees on a bus" (not a plane as using 802.11 there is > probably frowned upon, I haven't risked trying it to see if anyone > would notice...) who just happen to create an ad-hoc network, with > no external support at all.
okay. but there's a fairly fundamental conflict here between this use of LL (in a network that will never be connected to the internet) and the use of LL on a network that is only temporarily disconnected from the internet. apps need to know which kind of address to use. if they start assuming an LL-only network they won't be able to send referrals to nodes outside that network; if they start assuming a network with globals they won't be able to send referrals to LL-only nodes. and to try to use both kinds of addrs requires that the app know about network topology. bascially LLs and SLs create a big mess (if apps use them at all) and don't provide any good way to solve those problems. of course, many apps don't do referrals and don't have any problem with LLs or SLs (other than the problem of using LLs on a multiple-interface box) but some apps do, so when you use LLs and SLs for apps you get the confusing situation where some apps work (so the network is "up") while others fail in odd ways. I don't know how to solve this problem entirely, but I think it can be minimized by discouraging use of LLs when they're not needed, and by replacing SLs with a better mechanism. I do see a use case for LLs but I think we could provide SL-like functionality in a better way which was less confusing to apps, and at the same time solve the problem of allowing isolated networks (not having provider-based addresses) to privately interconnect to other networks without NAT. > | ISPs that pull that kind of stunt deserve to go out of business quickly. > > Unfortunately, that requires the customers to desert, quickly, which requires > yet another renumbering. well, if the customer is being forced to renumber, then the customer might as well switch ISPs at the same time... > And remember, that while an ISP could do this as a stunt, the more likely > cause is going to be the network (via a nanog or similar meeting) deciding > that the routing table is simply getting too big, too fast, and that some > realigning of addresses is required to allow topological aggregation to > work again with the network configured in the state that it has developed > into at the time. well, one hopes that nanog or whoever provides adequate advance notice, and that they don't try to force everybody to renumber at once. management of this kind of change will be tricky and I don't think anyone's demonstrated how to do it yet. > That is, it isn't a "stunt". And while you can argue that such a > change should be properly planned, my counter is that no amount of > proper planning is sufficient - surely being able to plan for this for weeks or months causes fewer problems than having 24 hours notice... though I don't pretend that we're anywhere close to having entirely painless renumbering no matter how much notice is given. (like 'painless dentistry' there is no such thing...) > I want connections to be able to > exist where the address will *never* change (other than at my specific > demand - no-one else can ever instigate it). yes, I understand that use case. I just think that there are better ways of providing for it than SLs. and I'm not saying we should forbid hosts or sites or apps from using SLs, nor that we should reallocate those addresses for other purposes - but I think we would do well to provide a better way to solve this problem and to recommend that non-routable global prefixes be used in preference to SLs. that way, apps wouldn't need to try to deal with SLs specially. > | to some degree this is govered by public perception about what is > | reasonable, and such perception can be influenced by standards. > | so we do have some influence here. we should try to use it. > > Yes. To do that in an honest way, we first need to decide how to > avoid requiring addresses with either topological or geographical > significance (both of which require renumbering sometimes). > The original (70's-80's) IP allocation scheme would be OK (allocate > 1 2 3 4 ... to however asks in the order they ask). Just make routing > work with that. Or, propose something else. don't even try to solve the problem of routing these things and accept that (at least for the time being) that addresses used in the public internet still have to be based on topology. have icann set up a web page to request a non-routable prefix which explains the limitations of such prefixes, accepts a credit-card # (for a one-time fee to cover the cost of maintaining the registry and web page only) and then assigns a prefix. another idea is to allow sites to pick their own in a 6to4-like fashion, say by taking some well-known prefix, appending an ethernet (or other) MAC address from a device in their possession, and then the rest of the bits are theirs to play with... two problems with that approach: 1) you probably end up with a /64 prefix which might be a pain for some sites, 2) the site can't sell the device with that MAC address to some other site :) > Hmm - maybe I'm not being clear, or you just missed my point. No > requirement for a site to connect to the public net, certainly. > A site that isn't connected just uses SL addresses as if they were > global addresses (they go in its disconnected DNS - or however it does > address lookups) and are used exactly like anyone else would use a > global address. The site boundaries are the ends of the net as we > know it, so there's no magic at all here. such sites often want to connect privately with other networks, though not to the public net. SLs aren't good for that. > To allow two disconnected sites to communicate, they need either > global addresses right, but to get those they (currently) need to connect with the public network, which they don't want to do. > Groups of sites, talking to each other, but disconnected from the "one > true internet" is something that the current addressing plans really > haven't allowed for, and should. agreed. and note also that some of those sites may be connected to the public network (not providing transit for the others), while others aren't connected. > | with global non-routable addresses, the site-id is carried along with the > | address, it's exposed as part of the address (assuming a reserved prefix > | for such addresses), it's returned in the same kind of DNS RR that carries > | a normal address. the address is globally scoped so there is no chance > | of mistaking an address from a remote site as being one from a local site > | or a different remote site. > > But there's no way to tell from the address that it is one that you > cannot reach from outside, which makes it annoying (at best) to pass > around. assuming a reserved prefix, an app could tell a non-publically-routable (NPR) address from a 'normal' address. but it still would have a difficult time knowing whether the address was usable to a random peer. as I said, it's better than SL, but it still doesn't solve all the problems. 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] --------------------------------------------------------------------
