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

[Iljitsch van Beijnum <[e-mail]>]

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
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------