Hi Tony,
At 10:23 AM 4/3/2003 -0800, Tony Hain wrote:
Margaret Wasserman wrote: > ... > Access control is also useful, and a simple form of access > control will be needed in IPv6. However, site-local > addresses are a poor form of access control for two reasons: > > - Site-local boundaries need to be at routing area > or AS boundaries (not convenient).
This is bogus nonsense.
Please stop using this rude and dismissive language. This is a professional setting, and it would behoove you to act professionally.
The need for site-local boundaries to be at routing area or AS boundaries has been discussed in the routing area and on the IPv6 list. It is required in order to maintain the "convexity" of sites which is needed to avoid situations where interally addressed packets will be discarded when there is an internal path available to the destination.
In order to make this work, the all-internal path to the destination always has to be the shortest path.
Bill Fenner, Alex Zinin, Steve Deering, Bob Hinden and I (along with a variety of other folks) spent a long time discussing this in various fora of the past two years, and we have not come up with any way to ensure that the internal path will be the shortest path (== site is "convex") without requiring that site boundaries be on routing area or AS boundaries.
Perhaps you have found a better way? If so, please share it with us. Otherwise, I will persist in believing what we established through careful analysis and extensive discussion.
> - Site-local areas cannot be nested. > > So, you can't have a site-local access control boundary for > your corporate site, AND a site-local access control boundary > that only allows the marketing department to use the fancy printer.
Within the site, there is no difference between the filtering characteristics of SL & any other prefix. If your argument is that a site can't have multiple subnets with the same prefix, well that is self evident.
My point is that there is a need for nested levels of "local" access. So, site-locals (which cannot be nested) will not work as the only method of "local" filtering or access control in a network. And, once you need to use another method, what advantage is there to also using site-locals?
Just because you have a site-local address for a node, and you and that node are in the same site, does NOT mean that you will be able to reach it. Just because you have a global address for a node, does NOT mean that you will be able to reach it. Since applications will have to deal with both of these situations, what advantage is gained by using a special site-local prefix for "local" nodes?
> Both Steve Bellovin and Brian Zill have proposed superior > access control mechanisms based on information being passed > in router advertisements, and I think they plan to combine > their proposals into a single, maximally beneficial, form.
They are not superior access control mechanisms. They result in exactly the same architectural state where some addresses on a subnet are private while others are global. These mechanisms could just as easily announce an FEC0 prefix, and the resulting internal filtering would be identical. What they loose is the ability to know that the peer networks have implemented the same filter as a backup.
The Bellovin proposal is superior because it allows for nested local access control.
"Private" and "Global" shouldn't be a binary choice. A local access control mechanism needs to deal with multiple levels of "private".
> The intermittently-connected site problem is often raised as > a reason for site-locals. This is an interesting problem, > and it would be very good to solve this problem, but > site-locals do not provide a complete solution.
You make statements like this without any explaination or justification. Stable addresses that persist across multiple connect/disconnect events to different providers are in fact one problem that the current SL approach completely solves.
Local connections will only survive disconnect/reconnect if they actually _use_ site-local addresses. This requires more than site-local addressing. It require split DNS (or a similar feature for whatever mechanism the application uses to get the address).
There is also a conflict between how you would want things to work, by default, to be friendly to intermittently connected sites and how you would want things to work, by default, to be friendly with mobile nodes. Which do you think will be more prevalent?
> So, while I think that the IETF needs to figure out a way to > address this type of network, site-locals may not be the best > way to do it, as they come with substantial costs for all > nodes, and don't fully solve this problem.
The IETF needs to address all the requirements BEFORE removing the tool that currently solves them. Doing otherwise is an irresponsible act.
Unfortunately, site-locals are not finished. And, there does not seem to be WG consensus about how to finish them.
So, by fighting for them, you are essentially fighting to leave the IPv6 WG in the "stuck" position that we've been occupying for the past couple of years.
Margaret
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
