It's a shame that not everyone could be at the meeting. IMO, it was one of those rare IETF moments in history where the room actually had a moment of clarity and actually was mostly on the same page. And I'm not saying this only because I personally am happy to see SL deprecated, but because even part way into the presentation, I was telling myself the WG is not going to be able to come to any decision today. But the mood in the room really did seem to shift during the discussion. I was simply stunned at the end of the meeting at the apparent clarity and decisiveness that had been expressed in the call for deprecated SLs. IMO, the room knew exactly what it was doing, and was also informed about what it was doing. It was not a forced decision.
I believe the session was broadcast on the mbone, so it must be archived somewhere. (anyone know where?) Anyone not at the meeting who cares about this issue really needs to listen to that discussion in its fullness; the minutes do not come close to capturing what happened during the meeting. Having said that, one of the great difficulties I have with SLs is that I don't see a viable "compromise" or "middle ground". Every proposal I have looked at either uses SLs in very restricted settings (e.g, disconnected sites), or ends up having to implement the full blown "multi-sited node" (even though try to claim otherwise). I find scenarios that argue for a middle ground to be an unworkable illusion. Consider a bottom line. If we say SL addresses are a reasonable thing for (say) home networks doing autoconfig, and so on, the reality will be that SOHO routers will find ways of creating zeroconf environments that enable SL by default. They will then be used in practice in huge numbers of home networks. Corporations will likewise be tempted to use them, since they seem to provide "permanent" addresses, and "stability" across renumbering. So, we have situation not unlike being half-pregnant. In practice, SLs will become widely used in many organizations. But, once you have wide usage in terms of independent networks numbered using SLs, you have the inevitable problem of what happens if a node is in two sites at the same time. I don't buy the argument that this won't happen much and that the market can fill the gap if there is a need (and the IETF thus won't need to do this). If widespread useage of SL in networks becomes the reality, devices will be forced to work in those enviornments. One simple example: at home, I have my home network with a DSL link to the internet and also a VPN connection to my corporate intranet. This is a *very* common operating configuration. (Does anyone believe this won't be a common environment?) If both the home and corporate network use SL addressing (as they will in practice), things just won't work right unless nodes implement the multi-sited node architecture. Thus, I continue to come to the conclusion that we can't have it both ways. We either deprecate SLs, or we do the full blown multi-sited node. Doing anything in between will not work well enough in practice (i.e., is equivalent to us putting our heads in the sand) and will lead to interoperability problems, failed communications, and a less robust Internet. Exactly the opposite of what I believe IPv6 is all about. Does deprecating SL addresses cause problems? Clearly yes. And we need to put our engineering minds together to take those problems on as work items and develop solutions. And in particular, better overall solutions than we have with SLs. But I think we can do this, and we should do this, as it will lead to a better overall long-term technical result. Touching on the most common reasons people seem to have for supporting SLs: > - Site-locals should be retained for disconnected sites. 1) The WG will need to take an an activity to develop a solution for dealing with disconnected sites. I know I'll get flamed at some level for this, but we need a short problem statement to understand the basic constraints. (like, has to work out of the box, has to ease the pain of merged networks, etc.) But this can be 1-2 pages long, I suspect, and shouldn't take a year to develop. I think we collectively already know the constraints, we just need to write them down. We might also list some possible solutions, just to give folk a warm feeling that there are resonable approaches here (others have already posted such approaches), and that the WG isn't just putting its head in the sand. Personally, I'm not worried about this problem because I believe we can find reasonable solutions that don't involve SLs. This isn't a fundamentally hard problem like, say, multihoming. > - Site-locals should be retained for intermittently > connected sites. 2) The WG will need to take on an activity to develop a solution for intermittantly connected sites. Again, here I'm not that worried. For example, we have a lot of IPv6 addresses. There is no reason from a technical perspective why intermittantly disconnected sites can't continue using a prefix from its ISP after it is disconnected. IMO, there is something fundamentally broken with the idea that ISPs will be giving intermittantly connected sites different /48s or /64s each time they reconnect. But in any case, there are again other approaches as well, e.g., those also developed in 1) above would apply here to. So, again I do not think this is an unsolvable problem and am comfortable with the idea that we can and will solve it. > - Site-locals should be retained for their access control > benefits. 3) The WG should continue exploring the simple site boundary security approaches (e.g., zill/smb drafts). It's less clear to me (personally) how well this work will pan out, but it's definitely worth exploring. Besides, there isn't really agreement that SLs provide a good security boundary model anyway, so it isn't clear that SLs are an obvious answer here. > - Site-locals should be retained as a means for internal > connections to survive global prefix renumbering. 4) This is strikes me as a nice requirement, but something we don't have a solution for, even with SLs. We need to accept that we have no solution and SL is doesn't really seem to be a help here. Or, if folk really think there is an approach, its high time we had an ID to look at that actually fleshed out the details. We've had attempts in the past, but they have been abandoned. Thus, in summary, I support the deprecation of SLs with the understanding that taking this step will require that we take on some additional work items. But I don't see lack of specific solutions to those work items today as being a reason to delay deprecating SLs. Thomas -------------------------------------------------------------------- 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] --------------------------------------------------------------------
