Subject: Re: [dhcwg] Muti-homing support.

From: HYUN WOOK CHA <[email-masked]>
Date: Tue, 05 Aug 2008 06:05:14 +0000 (GMT)

Hello, David.

After reading your reply, I would like to share my opinion as below.

<snipped>
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.
</snipped>

For me, it is unclear that the preference option is applicable for decision on forking servers. I think that that option might be most useful under single administrative domain. 
IMHO, one option is valid on-link prefixes to client from server's point of view. In case that a message from a client is relayed by a relay agent, server refers to link address in Relay_Forward message to identify where client is located. At this time, the link address can be associated with known on-link prefixes in server if any, or at lease the link address itself. And, the server responds with Advertisement with the on-link prefixes in a option, then client is informed with its on-link prefixes from this server's viewpoint. If multiple advertisements from different server DUIDs are received, the client checks whether two lists are same or not. If lists are not same, it might be safely inferred that the client is on multi-homed link and it requests to both servers for an IA options. Otherwise, the client select one server from preference option and send REQs to the chosen one.
In case the server receives any SOLICITs from the client directly, server can provide its local on-link prefixes for the serving interface.

Joseph

------- Original Message -------
Sender : David W. Hankins<[email-masked]> 
Date   : 2008-08-05 03:17 (GMT+09:00)
Title  : 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 6 Aug 2008 11:58:09 -0700

> For me, it is unclear that the preference option is applicable for decision on forking servers. I think that that option might be most useful under single administrative domain. 

Yeah, it's a pretty bad idea.

> In case the server receives any SOLICITs from the client directly, server can provide its local on-link prefixes for the serving interface.

I don't think a client can infer from multiple prefixes that there are
therefore multiple administrative domains.

I think it's possible one admin. would erect two servers, for fault
tolerance, expecting the clients to bind to only one of them (maybe
even setting the preference to prefer one prefix).

It occurs to me today - we (or I at least) keep talking about
disparate administrative domains.  Why don't we just make an option
that advertises the administrative domain explicitly?

Similarly to the choice a user expects in their desktop drop-down box
to select a WiFi network by name, a system could offer the choice of
multiple administrative sources of configuration by name (and perhaps
by URL), and default to 'all'.

But we're getting a little bit ahead of ourselves.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Aug 2008 12:07:57 -0700

> by URL), and default to 'all'.

I think this is probably a good suggestion.   To the extent that multi- 
homing is practical for an end-user (which I think is not very much),  
chances are it's going to be in situations just like this, where the  
user notices that the network is not working, and manually chooses a  
different network.

We could do this automatically, but it requires substantial changes to  
the way IP connections are set up, and these changes are not changes  
that anybody is working on, as far as I am aware.