RE: draft-baker-6man-multiprefix-default-route-00.txt is a newdraft

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              <james.d.carlson@sun.com>
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
--------------------------------------------------------------------