I think there are two separate, but related, issues:
One is the multiple interfaces issue on a host.
The other is the multiple interfaces issue on a RG (router/gateway or
routing gateway). The host behind the RG knows nothing of multiple
interfaces -- except in IPv6 it may see multiple prefixes and be
assigned multiple addresses.
For the host case, the host "knows" it has multiple interfaces and could
do things specific to those interfaces.
The issue for the RG is how does it present information it obtained from
multiple sources (ie, different upstream DHCP servers) to the host as
the host only believes there is ONE interface with multiple
prefixes/addresses and a single set of configuration data. (And in
DHCPv6 we're supposed to be using globally unique addresses and no
NATing so the decisions can't be made at the RG as would be possible in
DHCPv4 -- since then the RG could chose the address it uses for
communicatio with the outside world.)
I again don't see how the container option really changes anything -- as
it just allows the RG to be told what to potentially pass on its clients
(rather than having to pass on information it itself is using).
How realistic is that most RGs with multiple interface will connect to
DIFFERENT service providers? And, in the case where they do, this likely
means someone (the owner of the RG) has to make some decisions --
requiring appropriate configuration.
- Bernie
-----Original Message-----
From: Giyeong Son [mailto:gson(_at_)rim(_dot_)com]
Sent: Wednesday, April 15, 2009 9:53 AM
To: Ted Lemon; Ralph Droms (rdroms)
Cc: mif; ietf(_at_)ietf(_dot_)org; Black_David(_at_)emc(_dot_)com; dhc WG;
gen-art(_at_)ietf(_dot_)org;
Bernie Volz (volz)
Subject: RE: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
I think Ted pointed out very interesting but crucial problems if I
understood correctly. So, I'd like to confirm what Ted indicated and
emphasized:
1. How to dynamically/automatically/efficiently enable and manage
multiple active interfaces on a host?
2. How to utilize multiple active interfaces on a host?
2. What are the efficient (or cost-effective) routing decision policy?
Is it least cost routing policy? Or other? If it is least cost routing
policy, what are the costs? Are they "money" to use the connection (e.g.
WiFi vs. cellular), "time" to spend for the transmission, "reliability"
of the transmission, etc?
If those are what Ted indicated, I am also interested in asking if the
above things are in scope of MIF. Based on my experience in terms of
simultaneous use of multiple interfaces, the aboves are the most
critical and interesting issues in practice in order to utilize the
network environment of simultaneous use of multiple interfaces reliably
and efficiently.
Giyeong
-----Original Message-----
From: mif-bounces(_at_)ietf(_dot_)org [mailto:mif-bounces(_at_)ietf(_dot_)org]
On Behalf Of
Ted Lemon
Sent: April 14, 2009 5:48 PM
To: Ralph Droms
Cc: mif; ietf(_at_)ietf(_dot_)org; Black_David(_at_)emc(_dot_)com; dhc WG;
gen-art(_at_)ietf(_dot_)org;
Bernie Volz
Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
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.
_______________________________________________
mif mailing list
mif(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mif
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf