On 13 nov 2007, at 13:46, James Carlson wrote:
Matter of fact, it seems to address something that also occurs with
IPv4, with multihomed hosts. And that apparently, some OSs screw up
royally.
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?
No, of course not. But how often do applications bind a socket to a
specific source address? Even for daemons this is not a given.
The situation that needs addressing is the one where through
configuration mechanisms such as router advertisements a host
configures multiple addresses and also multiple default routes, and
after that, the host picks a source address and a default route that
don't "match" while such a match is enforced upstream in the network.
The simplest example of how this happens is when you have two routers
with two independent connections to the outside world that both send
out RAs for a prefix delegated by the ISP that router connects to.
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.
Right. There's also the case where the application or part of the
system knows about different addresses and tries to probe for a
combination of source address, destination address and route that
works. (Such as the shim6 REAP protocol is designed to do although
REAP doesn't know about routes.) So it should clearly be possible to
send packets that don't conform to the source address / route
alignment. However, having this alignment by default would be good.
I'm not so sure that routers correcting "misbehaving" hosts here by
selecting a different route based on the source address is a good
default behavior, though, as this could make for a performance hit.
(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.)
That's not going to happen. Even in cases where you pay an ISP $$$$ it
can be hard to get this done. When you pay an ISP $$ this isn't even
remotely an option unless we can come up with an automated way of
opening up ingress filtering holes. And something like that would take
many years to see wide deployment.
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.
Source routing = the source determines (part of) the path packets take
through the network
Source address dependent (SAD) routing = routing decision at this
particular hop may be influenced by the source address in the packet
They are very different.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
