Re: [dhcwg] Muti-homing support.

["Bernie Volz (volz)" <volz at cisco.com>]

I'd still like to see a real network diagram for this issue.

Joseph had:

           Server
             | 
    |----------------| 
  RelayA            RelayB 
    |----------------|
             |
           Client 

and

  ServerA         ServerB
     |              |
  RelayA          RelayB
     |--------------|
            |
          client

But the routers are missing here. The multiple connections to the ISPs
are missing - where are these located; how are they connected into the
network. Yes, I understand that the "|" elements could be replaced with
"cloud" but that still misses the point.

The ONLY purpose of a Relay Agent is to avoid the need to have the
server directly on that network. It does nothing else. The DHCP model is
that the server and client are on the same link and hence the server has
to have full information about that link. Relay's allow you to move the
server elsewhere in the network, but it does NOT change the fundamental
assumption about what the DHCP server has to know and what it is capable
of doing.

- Bernie

-----Original Message-----
From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf
Of David W. Hankins
Sent: Monday, August 04, 2008 2:17 PM
To: dhcwg at ietf.org
Subject: Re: [dhcwg] Muti-homing support.

Bernie is spot-on on the first case.  Couldn't have said it better
myself.  On the second case;

On Sat, Aug 02, 2008 at 11:18:03AM -0400, Bernie Volz (volz) wrote:
> In your second case, again, I don't see a problem. The two servers
will
> provide different addresses but again they should be providing
addresses
> valid for the network (link) the client is on. If that network (link)
is
> multi-homed, BOTH servers should be providing addresses on those
> different prefixes. If the servers are not configured to do so, yes,
you
> will have problems but that is a configuration error and not a
protocol
> "defect".

At David Thaler's presentation on IP's meandering path (don't recall
the WG, was that INT-area?), I mentioned in passing that it was
curious to me how often we seem to fail to write protocols that can
withstand common everyday administrative boundaries.  Everyone seems
to assume that there is always only one operator who can take care of
all of our needs behind the scenes.

In the second case here, it maybe isn't obvious that the two DHCPv6
servers are very likely being operated by totally different
administrators...not just different groups within a company, but
entirely different companies that are probably competitors and more
than likely don't trust each other and probably spend their spare time
insulting each other on local mailing lists or, in the old days, the
newsgroups.

It is going to be a very "hard sell" to suggest that two competitors
colocate a critical component of their services on a single DHCPv6
server that they're both going to have some part in configuring.  "He
is a crook who will sabotage our business!" the first one will say.
"He only says that because he's thinking of doing it!  Plus, they are
incompetent, and will blame their mistakes on us!" the second one will
say.

Alternatively, it would be a wonderfully easy sell to suggest that if
two competitors both use DHCPv6 to deliver configuration to a common
client via separate servers, then they can use various tricks (like
having the lowest IPv6 address) to make sure clients reliably choose
one server or the other, depriving their competitors of traffic in a
traffic-billed environment, or shunting all traffic to their
competitors in a monthly-billed setup.

> There is an assumption (probably unstated in RFC 3315) that when
> MULTIPLE DHCPv6 servers are present, that they are effectively
> identical. There is no requirement that they give identical answers
(in
> fact it is expected that they likely will not), but that a client will
> end up with virtually the same service regardless of which server is
> selects.
> 
> If this is not the case (which technically there is no requirement for
> it to be), what service the client gets does depend on which server's
> answer it accepted. (This is exactly why rogue DHCP servers can be a
> real problem.)

This tracks with my understanding as well.

> Note that none of this is new. This has been the way DHCPv4 has been
> working for a long time. DHCPv6 makes multi-homing easier (and
possible
> via DHCP), but that doesn't change the basic assumptions.

IPv4's "multi homing" spiel is different from IPv6's.  This was one of
IPv6's oft spoken of selling points.  You were supposed to be able to
get redundant paths at home.

Supposedly you're supposed to be able to have a small home network
and just put multiple vendors' set-top boxes down and get net every
which way.  Plug and play, so they say.

RS/RA supports this.  DHCPv6 does not, as we both seem to agree.  This
means IA_PD does not.

Fantastic?


I don't know if we need to have an answer for this, since two of the
three of us seem to think so.  Maybe the answer that "DHCPv6 just
doesn't do that" is good enough, because someone could just make a
second layer home set-top-box that takes N connections from ISP's and
presents one (NATTED? PD'd?) image downstream to the house.  I don't
know.  But how this is supposed to work, if it is supposed to work
with DHCPv6 anywhere in the picture, is a valid question which I am
not clear on either.

There's currently no guidance for clients to enable this topology, and
the best I can think of is pretty lame; to fork servers when the
preference option's contents is equal.  The battle of the preference
option between two competitors would escalate quickly.


It seems to me that this is an area DHCPv6 could do better than RS/RA
on.  Renewing to a remote server means testing the path that is most
likely to fail in a home network; the individual customer's link.  It
seems more likely that a set-top-box would continue to RA for prefixes
it can't deliver on.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg