Margaret Wasserman wrote: > 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.
Then why do you insist on claiming that filtering a prefix at existing route filtering boundaries is 'not convenient'? It is not my intent to be rude, because I really have no idea why such bogus comments are thrown in. They appear to just be FUD intended to sway opinion, particularly when you turn around and make technical counter arguments at other times (like here). > > 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? Your assertion about nesting is ambiguous. I can certainly have a network with a pocket of independent SL inside it. Routing between it and the rest of the network would not be possible without globals, but in some situations that is exactly what is required. It is also possible to have multiple levels of filtering within a site using the FEC0 prefix that match area boundaries. The advantages of using it don't change; it doesn't cost anything to get, internal communications are isolated from external prefix changes, and if a configuration error occurs at the border the world will be configured to ignore the prefix so the network exposure profile is lower. > > 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? Applications aren't supposed to work when there are filters in place. Network managers have a requirement to isolate some nodes from parts of the network, so they will filter. A well-known prefix allows everyone to block the same space so errors are not as dramatic. An additional value of a special prefix that keeps being ignored is the ability to have appliance devices configured to use it by default. This drastically reduces the manual configuration required for large networks. > > > > 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". FEC0::/10 provides 54 bits for local structure. Since 'private' space is simply filtering of routing information, there is ample opportunity for multiple levels of private space. I am glad you agree that Private & Global shouldn't be a binary choice, so we can drop all discussion of the 'exclusive' option. > > > > 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). If topology information is exported outside its scope of relevance, the process responsible for doing that is broken. This is true even when the topology information is not ambiguous. For truly local connections, split DNS is not required. Where that becomes a requirement is for applications that leave the local context. Even there, the application *could* be intelligent enough to recognize when the /48 doesn't match and ignore any SL that it might have gotten back. > > 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? A mobile node knows that it is mobile, while other devices in a site won't have a clue about the connection state at the border. If you want to count devices, it is currently heavily weighted toward intermittent, and upcoming the stationary appliance market will easily exceed the mobile node market because people have many more appliances in the home or office than mobile devices they are willing to carry. In any case, there is no reason not to set the general default to SL, with mobile nodes having the opposite. When a MN knows it is not home (which it has to know to contact its HA), it should simply ignore any SL. > > > > 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. No, I have been stating that we need to solve the perceived problems in better ways FIRST. People will choose the path of least resistance. If we provide them a better tool that actually meets their requirements, they will move of their own accord. If we try to remove the tool because we are afraid, and offer only a vague promise that we might get around to it if we ever agree that their requirements are worth our valuable time (re: MW- I do not believe that we want to impose a costly and complex solution on _all_ IPv6 nodes so that a few of them can work properly in this unusual situation.), they will consider the IETF irrelevant and will make their networks work. Whatever that takes. I don't want the WG stuck, and have been working on an addressing plan that would in fact help with the address uniqueness case. I have not brought it to the WG because it was initially targeted at the multi-homing issue. If you would like me to submit it as a WG draft for consideration as a mechanism for unique values that don't require a registry, I am willing to do that. If it were coupled with the Bellovin/Zill RA, many of the requirements would be dealt with. That does not mean all are solved, so we still have work to do before deprecating SL. If we do it right, once we address all the requirements, nobody will even care about SL. At this point we don't even know if we can address all the reqirements with other mechanisms, so if we continue down the current path of doing it wrong, chaos will reign. Tony PS: I forwarded my SL requirements draft to the ID editor earlier today as a personal draft. If there is interest in that becoming a WG document, I will change the name and resubmit it. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
