Ole, Question: So what would you suggest in wording that we can provide to state that this should be the case to prevent any notion of SLs being forwarded in our specs. Rather than just trust the good intentions of suppliers? That might be the BCP. But we cannot leave it as it is per this discussion. I would like to not have it again on the list.
What is your suggestion? thanks /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Ole Troan [mailto:ot@;cisco.com] > Sent: Wednesday, October 30, 2002 6:31 PM > To: Jun-ichiro itojun Hagino > Cc: Richard Draves; [EMAIL PROTECTED] > Subject: Re: Limiting the Use of Site-Local > > > >>> A router might (and probably should) be hard-coded not to > >>> forward link-local packets, as there is no reason to ever > >>> forward them. > >>> > >>> However, a router that might ever need have multiple > >>> interfaces in a single site can't be hard-coded not to > >>> forward site-locals. Whether or not they will be forwarded is > >>> the result of configuration. > >> > >>Actually, a router can forward link-locals between > interfaces on the > >>same link. In particular, a router can forward a packet with > >>link-local dest and/or source back out the interface from which it > >>arrived (and presumably generate a Redirect too). > >> > >>If you are implementing link-locals properly, it's really > very little > >>additional code to support site-locals. At least that's my > experience. > > > > could you comment on routing code? (RIPng, OSPFv3) i > still think > > it's way too tough to support multi-sited node. > > RIPng is relatively simple. link-state protocols require > congruent areas and sites. there are some open issues with > regards to multicast and PIM I believe. routing protocol > support is required in any case for VPNs. > > site-locals can be used without multi-site support, i.e > treated pretty much like globals. multi-sited-ness shouldn't > be recommended for other reasons than adding complexity to > routers, e.g DNS issues. > > /ot > > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
