Kacheong Poon writes: > James Carlson wrote: > > > I don't see how that's relevant for a user trying to support systems > > with LLAs. Moreover, I don't see how it matters -- the protocols will > > all work properly, even if the address is chosen in some "non random" > > fashion. > > > Not knowing exactly the reasons behind why the RFC explicitly > states that and assuming that the authors and the WG behind > the RFC made a conscious decision, I am not sure if we can > just say that it is not relevant.
These RFCs describe what implementors need to do in order to acheive interoperability. They do not constrain the hands of those deploying or using the protocols. In other words, if you _need_ to do something, don't let a document stand in your way. ;-} > > Without that, though, the usual rules apply: when we try to send a > > packet, we look up the destination address in the forwarding table > > first. If we find a route, then that's where we're going to send it. > > If we don't find one, then it hits the floor. > > > Are you trying to say that since either way is a hack, so why > one way but not the other? Not exactly. I'm saying that if you want to talk to LLAs, you need a solution. The solution can be a modification of the stack to understand LLAs, or it can be a fairly simple and straightforward hack. (I called originally it a "cheat," but the idea is the same.) > > It doesn't matter, because it doesn't work. > > > It works sometimes, just not "all the time" :-} No. It cannot work at all. Consider a system that has a single interface and fails at DHCP. It sets up (let's say) 169.254.21.12 as its address, randomly chosen per RFC 3927. We also have (on the same subnet) a system with address 10.0.0.1/8. This system is running Solaris and has no idea about LLAs. The LLA system finds it needs to talk to 10.0.0.1 (for whatever reason). It sends an ARP query for 10.0.0.1 (per section 2.6.2). The non-LLA system responds (it's a valid ARP query, and ARP doesn't care much about subnets), and the packet gets sent and delivered, because the LLA system thinks of all destinations as being local. Now the system at 10.0.0.1 tries to respond. It looks at the remote address -- 169.254.21.12 -- and tries to find that in the forwarding table. That doesn't match the local subnet (10.0.0.0/8). Most likely, it matches a default route and gets sent to a local router. There's no way for the 10.0.0.1 system to send packets back to the LLA system. If the protocol isn't just unidirectional (other than UDP syslog, most aren't), then this means failure. Thus, I don't see how what's suggested here could possibly work without modification of that non-LLA system. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
