> > ... > > such a policy would also make it dysfunctional. it's=20 > > completely bogus for such devices to impose constraints on=20 > > how a network is designed. > > I am talking about default. If you want to change the policy to allow > global access you should be able to do so, but there is no reason we > should create an open dos problem when we don't have to.
so what you are saying is that IETF should legitimize the idea that security scopes and network topology coincide. we *know* this is unwise. > > oh right, so we need to configure each application to be > > aware of network topology to know when to use and when not to use SL. > > Your input channel was shut down long ago. I was not arguing that the > app know about network topology, just that it is aware of its own > ability to deal with scope boundaries or not. If an app knows there are > failure modes when crossing scope boundaries, it should have an option > that prevents it from getting into that state. This is nothing more than > a flag that says 'this socket must be considered global scope'. just saying "apps that can't deal with SLs shouldn't use SLs" doesn't work because sites that use SLs will expect that apps work with SLs, and that global addressess aren't needed. there's no way that an "option" will keep the app from failing in that scenario - at best the app can try to detect the reason for the failure. even then, an explanation of the form "this app failed because it couldn't communicate between node Z1 and node Q3 because Q3 seems to only have site local addresses" isn't likely to cut it - the customer will demand that the app support communication with SLs only to later find out that this still doesn't help because Z1 and Q3 (or perhaps a different pair of nodes) don't share a common scope - meanwhile the app has acquired 10k more lines of code and its behavior has become less predictable. and the customer will then demand that the app support internal addressing and routing, because for some reason the network addresing plan is deemed to be carved in stone - even though it was based on a flawed design - and the app isn't. SLs are a lot like A6 records - they will work fine *if* you understand the constraints. but the constraints are even hard for IETF people to grasp. we're better off without both. as for *my* input channel... how many distributed applications have *you* tried to patch to deal with scoped addresses? > Despite the validity of the assumption, > network managers want the ability to have some devices addressed in a > space that can't be globally routed. just because newtork managers want something doesn't mean that IETF should complicate everyone's lives by giving it to them. large numbers of network managers have been deluded by snake oil salesmen. if IETF starts catering to salesmen-induced delusions we may as well go back to using carrier pigeons - since it will work better than the Internet. > The kinds of apps you are worried about don't apply. and who are you to say that (just to take one example) SIP doesn't need to be able to complete calls across scope boundaries? > Peer-to-peer apps can use SL, as long as they are 2 party. When an app > is willing to deal with more than 2 parties, it knows that and should > have a means to refuse SL addresses if there is an alternative. easily done, *if* there is an alternative. but if the alternatives exist, why bother with SL at all? it's easier to implement a sane filtering policy with globals. 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] --------------------------------------------------------------------
