Margaret Wasserman wrote: > At 10:26 AM 8/7/2003 -0700, Tony Hain wrote: > > > Right now I cannot find a single application where locally scoped > > > addresses give me anything worth the effort. Those are my > 5 cents - > > > since you asked for > > > details :-) > > > >Wait, you started off by saying that you really need to > filter and keep > >some addresses local use, but then turn around and say you > don't have > >any application for that. Which is it? We agree there is no need for > >you to have ambiguous addresses, but you appear to have a > requirement > >for range limited addresses because you intentionally > filter. Getting > >back to the question, is not trusting the hosts the requirement? > > "Range limited addresses" could mean two things here: (1) > Addresses that inherently have limited range, or (2) > Addresses that effectively have a limited range, because the > entire address is filtered at some boundary.
With that choice of terms, the only way to create (1) is to predefine boundaries for network managers. Since that is not something the IETF can do, the only useful meaning is (2). Is the distinction you are trying to describe is automated vs. manual filtering ??? When the goal is automated, a 'well-known' prefix simplifies the boundary device implemention. > > There is also a third alternative... Port/Address filtering. > It may be that a particular address has limited range on > some ports, and is globally accessible on other. See the thread: Multi-homing (was ......]]) for why port filtering is not viable in a consumer environment. It is much simpler to have each host take care of its own global/local accessability than it is to get it right in a remote edge box (witness regular configuration failures by trained IT professionals). The multi-app case is also easier to deal with if there is an obvious differentiation in the address for each app to bind to. Yes that means apps should be halfway intelligent, but it they choose not to be the worst that happens is delay. > > So the fact that someone uses filtering does not necessarily > imply that they have a need for addresses that inherently > have limited range. Assuming 'inherently' means 'well-known', yes it is true that manually configured filtering does not *require* a well-known prefix. It is also true that automation is required for consumers. Just because it is possible to do manual filtering doesn't invalidate the requirement for automated simplicity. We need to stop propagating the idea that requirements are invalid when - 'if the user was educated they would just do it my way, and they aren't educated so they shouldn't be doing it'. By definition consumers will not be technically educated, so approaches that work in a large managed network will simply fail. They need something as simple as; light switches by default are only accessible internal to the home, but if say the front porch light needs to be exposed they can explicitly configure it to be global. Technically they could (A) go to a border router and block the light-switch port, then figure out which address the front porch light had and allow it to pass, or (B) they could buy a box that filters a local range prefix, and a light switch that the ability to configure an additional prefix for global access. (A) requires them to know technical details whenever any new appliance/app comes out, and get an IPv6 address configured (without typo's) into a border device. (B) requires the light switch vendor to provide a configuration of limited-range by default, with a mechanism to add a global prefix when required. In other words, (A) puts the cost on the consumer, while (B) puts the cost on the app developer. Since the consumer will always go for the lowest cost, and the app developer has the technical capability to figure out automation, (B) will always win in an open market contest between the two. Unfortunately the IETF is overpopulated by app developers looking to move the cost out of their scope. While many are complaining that putting the cost in the app is too painful, the alternative is putting the cost on the end consumer. That is even more painful, and aligned with the point where the financial decisions are made. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
