Roy, I agree with you but another point I really don't like. In the situation in same site per your statement below. A node could send to a dst addr with less scope in its src. If the packet goes far enough it can never return (kind of like charlie on the MTA in Boston). Another property of SL I don't like. But before we gave imnplementational and operational real thought to SLs and lumped them in IPv6 we had this same problem. With Link-Local. What is the point of sending to a global address with a Link-Local? That's unidirectional. Just another point of darkness about SLs.
/jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Roy Brabson [mailto:rbrabson@;us.ibm.com] > Sent: Monday, October 28, 2002 3:58 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: Limiting the Use of Site-Local > > > > I have a basic problem with this thread. We have a few people > > discussing fundamental changes in close to a vacuum. At best the > > result of this discussion should be a separate BCP, but before that > > happens operators of networks that actually use 1918 space > need to be > > engaged to find out their requirements. > > > > The whole idea that SL should be revoked if a global is > available is > > bogus. It is certainly reasonable for the manufacturer of light > > switches to only support SL/LL rather than potentially > multiple global > > prefixes. There is no reason for those devices to interact across a > > scope boundary, so the peer nodes that may also need global access > > MUST keep their SL to interact in the limited scope. > > I thought global addresses could be used to communicate with > peers using > addresses of any scope as long as the interface over which > the packet is > sent is in the same scope zone as that peer. As such, a node with a > global address does not require a site-local address to > communicate with a > node which has a site-local address but lacks a global > address, as long as > the two nodes reside within the same site. > > Roy > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
