Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

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(_dot_)Lemon(_at_)nominum(_dot_)com>:
> 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(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf