Manfredi, Albert E writes: > Matter of fact, it seems to address something that also occurs with > IPv4, with multihomed hosts. And that apparently, some OSs screw up > royally. Which is, if a multi-homed IPv4 host, connected to two > different IP subnets, transmits an IP packet over Subnet A, it often is > found to use as source address the address assigned to its Subnet B > interface.
I don't agree that those OSes "screw up royally." They are, in fact, doing what their users *tell* them to do. If an application binds the source address on Subnet B and then sends a packet with a destination address that's either best reached or *only* reachable over Subnet A, then what's the system to do? Should it send it over Subnet B -- in violation of the local forwarding table -- and hope the next hop router can deal with the problem? Should it disregard the application's source address binding and set the source address to conform with the output interface? Should it just drop the packet and pretend it can't send anything? No matter what the system does here, it ends up violating basic functional expectations that the user may have, and that's a Bad Thing. I agree that the underlying problem is common and one worth solving, but I think doing so needs optional OS features to allow the user to specify which expectations can be violated and under what conditions. That sounds vaguely outside the normal IETF boundaries to me. (The underlying problem is, to me, just a lack of reasonable routing policies. If a site is multihomed like that, then, at least in a perfect world, both ISPs would know about _both_ subnets in use, and that the same customer has a legitimate claim on both.) > I agree that calling this "source routing." or anything similar, would > be misleading. It *is* making packet routing decisions based on the source address. Perhaps that's not exactly the same as "source routing" used in other contexts, but for the first hop, it's the same thing. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
