On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote:
Now, I admit I'm describing a hypothetical and abstract scenario. I don't have a specific example of a situation in which a host might make decisions - either in the stack or in an application or ??? - about outbound traffic based on knowledge of how that traffic would be forwarded by the RG.
That's right. But I think it's not an accident that this is a hypothetical scenario. In reality, a scenario like this has been likely ever since wireless and wired network interfaces became standard on laptops. And yet we don't have any real-life examples of problems that this has caused, which need solving. To me, that seems like an indication that this is not a real operational problem. That is, that the answer "if two DHCP servers send the same client conflicting information on two different interfaces, that is a misconfiguration, and should be solved by correcting the misconfiguration" is, in practice, the correct answer.
If it were not, we would be hearing about concrete, real-world scenarios of the type you describe, not about hypothetical ones.
I don't mean to minimize this issue - if in fact there is some future real-world scenario where this would be a serious problem, it would be good if we could anticipate it. It might be profitable to consider analogies.
For instance, right now I have IPv6 set up at home. Because IPv6 isn't deployed at all in Tucson, the way I have this working is by tunneling. Since there are two tunnel brokers offering service for people like me, and I am a bit adventurous, I have two tunnels. Right now, every IPv6 packet I ever transmit goes out one of those tunnels, with the exception of packets destined for a specific net, for which I have defined a static route.
First of all, this scenario works just fine. Both tunnels are configured as a default route - it just happens that Linux's route selection process always chooses the first one. This algorithm would work poorly if one interface were preferable to the other, but since both are equivalent it's not a problem.
Second, though, why do I have a default route configured? It's because I'm talking to a node on that network that will only answer if I use the source address of one of the tunnels; and will ignore any packets I send it with the other source address. So in the case where there was a problem, I manually configured a workaround.
How could we automatically solve this problem? Simple: any time we are initiating communication with a device on the network, and do not know that the communication is going to work, we simultaneously start the communication in every plausible way. So suppose that there are two AAAA records corresponding to the machine I want to talk to, and I have two global IP addresses. I'm going to send four syn packets. The first syn-ack I get back is the one I'm actually going to use - I'll send RST packets to the other three.
This is analogous to the solution Stuart Cheshire described a couple of IETFs ago to the problem of IPv6 causing connectivity problems instead of expanding connectivity opportunities - you can't prefer one solution over the other, because you have no basis for doing so, so you have to try all possible solutions and choose the one that works best. My only extension, if it is one, is that I've added the source address to the matrix - I'm not sure Stuart mentioned that.
Now, how does this extend when we go to DHCP? Suppose I have DNS resolver configurations from two DHCP servers. I try both in parallel. I can winnow it down a bit: since I received the DNS server information from one DHCP server on one interface, and the DNS server information from the other DHCP server on a different interface, I only have to try to query the DNS server using the source addresses of the interface on which that DNS server's configuration information was received.
But how do I do that if the device that has two interfaces is not the device originating the query, as is the case with the container option? I think the answer is that I can't. There is no heuristic that I can define that will always make the right choice, because the device receiving the container options has to make the choice for the client.
In DHCPv6, we could at least give the client a hint about what to do as follows:
Suppose that I am dual-homed. I ask for, and get, a container option on both outward-facing interfaces. I also wind up configuring one or more prefixes as a result of my communication with the DHCPv6 server on these two interfaces. I wind up advertising prefixes to the client based on the answers that I get on both outward-facing interfaces, so for example if I get a single prefix delegation from each DHCPv6 server, I will advertise two prefixes to the client. So when the client asks for, and gets, IA_ADDR configurations for both prefixes, I include the container option information from each DHCPv6 server in the IA_ADDR option for the prefix provided by that DHCPv6 server. Now the client has enough information to make a choice - it can use the source address for the prefix from a DHCP server to communicate with the DNS servers provided by that DHCP server.
But this requires a great deal of complexity on the client, and on the server. Is this complexity that we want? And we haven't even talked about the case where either due to cost considerations, or due to speed considerations, one interface is preferable to the other. How would we communicate that? How would we configure that? Supposing that one prefix is more expensive than another, does the client then not try the expensive prefix until it's timed out on the cheap prefix? What does that look like to the end-user? Does it fail gracefully?
So I think it's an interesting problem space. And actually I think that you could come up with heuristics that would work most of the time, potentially at the cost of increased load on name servers, and increased network usage, and the occasional $1000 cellular data bill. But to come up with heuristics that will work the right way every time, I think that is very difficult.
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf