Hi, Ted, Excuse me for my late comment, I try to catch this thread. For the case of the device has two interfaces which originate query. Your suggestion looks quite interesting: try every plausible way. I guess this is interesting topic in MIF future work. And you talked about Stuart Cheshire described a couple of IETFs ago, Could you help to point out the link? many thanks -Hui 2009/4/15 Ted Lemon <Ted.Lemon@xxxxxxxxxxx>: > 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. > > _______________________________________________ > dhcwg mailing list > dhcwg@xxxxxxxx > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf