Hi All, On Tue, 2002-10-29 at 04:42, Bound, Jim wrote: > Michael, > > Comments below. > > /jim > [Have you ever seen the rain coming down on a sunny day] > > > > > > Margaret, > > > > > Besides, it would be possible (although perhaps not > > > adviseable) to enforce this restriction. Nodes could immediately > > > deprecate site-local addresses whenever a global address is > > > configured. > > > > I think this is a terrible idea. I can envision many > > situations where a host would need both a site-local and a > > global address. > > I think this is a wonderful idea and would like to see it applied to src > address selection as MUST. >
I agree. When I first put NAT in place for a customer (way back in 1995), I thought it was great ... until we tried to push Netbios packets through the NAT device, which it didn't understand. It was only after understanding what was happening did I realise the issues with NAT, at which point it was too late. The problem with NAT today is that it appears to work, and appears to work well. It is only getting "better" as more and more application handing code is put in NAT devices. By the time you find its limitations, it can be too costly to replace, either in terms of time, money, or just trying to motivate the "powers that be". I'd hate for the same thing to happen with SL under IPv6. While a number of people are posting to this list showing how Site Locals could work in conjunction with Globals, I think the question is just because SLs could work with Globals, _should_ they work with Globals ? In my experience, most network admins today tend to have a view that if it appears to be working, it must be ok to use it that way. I fear that SLs and Global combinations will fit into this category. Non-obvious reasons to avoid it just aren't a factor. I've met very few network admins that have ever read BCPs, let alone know they exist. I'd like to see the combination of SLs and Globals fail as per Margaret's suggestion. If necessary an override switch could be put in the device to disable this behaviour. At least this would provide a higher hurdle for less informed net admins to jump when trying to implement something that isn't the best thing for their network. Mark. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
