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).
Good point.
If you are implementing link-locals properly, it's really very little additional code to support site-locals. At least that's my experience.
I agree that, in terms of _stack_ complexity, site-locals don't add much. The additional complexity comes at other layers -- routing protocols, DNS, applications, transport protocols, management apps, etc. Some of these complexities don't apply to link-local addresses, because no one expects to put them in the DNS, exchange them in routing protocols, or use them in upper layer protocols, except as a last resort (when the single link _is_ the entire network). I am essentially suggesting that we treat site-locals the same way -- use them only as a last resort when the site _is_ the entire network. Link locals already cause problems for management protocols. For example, it won't be possible, using the IP address of a BGP peer from the MIB (which will be link-local), for a management station on another link to find that host and communicate with it... So, it probably would have been better to use global addresses for routing protocols and limit their hop count to 1. Oh, well. Margaret -------------------------------------------------------------------- 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] --------------------------------------------------------------------
