Subject: [homenet] the problem of two DHCPv6 servers on the same link

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jul 2013 17:04:23 -0400

Ted Lemon <[email-masked]> wrote:

    > On Jul 5, 2013, at 9:18 AM, Michael Richardson <[email-masked]>
    > wrote:
    >> To the extent that one sees two DHCP servers because one has two
    >> interfaces, MIF has some solutions.

    > Right, MIF is working on dealing with the issue of multiple
    > provisioning domains on the same wire as well. Don't mistake the name
    > for the referent.

Yes, but... it falls outside of the minimal-changes-to-hosts bin.

While hosts with multiple interfaces have a clear incentive to deploy
MIF-solutions (and the people who sell the 3G/LTE often control the host),
it isn't clear to me that a host with one physical interface (having only the
untagged VLAN configured), has any knowledge or incentive to deploy MIF.

Does the DHCPv6 spec what a host is supposed to do if it gets two answers when it
does DHCPv6?

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Jul 2013 17:45:37 -0400

> Does the DHCPv6 spec what a host is supposed to do if it gets two answers when it

It can pick or take both.   I need to do some experiments, I think.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 6 Jul 2013 11:34:31 +0900

On Sat, Jul 6, 2013 at 6:04 AM, Michael Richardson <[email-masked]>wrote:

> Does the DHCPv6 spec what a host is supposed to do if it gets two answers
> when it does DHCPv6?
>

I believe per spec it must pick one of the offers it receives. Technically,
it's not forbidden from initiating a *second* DHCPv6 transaction where it
can pick another result in addition to the one it already has, but I
believe no implementation does this.

[One of the many reasons why DHCPv6 is not a good fit for loosely-managed
home networks like homenet.]

---

From: Chris Grundemann <[email-masked]>
Date: Wed, 31 Jul 2013 12:04:22 +0000

On 5/Jul/13 20:34 GMT+02:00, "Lorenzo Colitti" <[email-masked]> wrote:

>On Sat, Jul 6, 2013 at 6:04 AM, Michael Richardson
><[email-masked]> wrote:
>
>I believe per spec it must pick one of the offers it receives.
>Technically, it's not forbidden from initiating a *second* DHCPv6
>transaction where it can pick another result in addition to the one it
>already has, but I believe no implementation does this.
>
>

Hi Lorenzo,

Pardon my ignorance, but why is this (can you expound a bit)? I think I'm
missing something here...

PS - Apologies for the latent reply, I missed this message when it first
came across.

Cheers,
~Chris

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 31 Jul 2013 14:35:04 +0200

> missing something here...

Examples:

   - It only supports choosing one lease in a given transaction, and not
   merging multiple sources of information (i.e., the problem mentioned above).
   - It's not suited to supporting arbitrary topologies because it only
   supports one-directional leases, from up to down.
   - It's not suited to supporting dynamic topologies. Information received
   via DHCP is hard to change. It requires that the client support dynamic
   reconfiguration, and even that doesn't work if the DHCPv6 server crashes or
   is unplugged.

It's likely that the above can be worked around with varying degrees of
hackiness and reliability, but the end result is likely to remain hacky and
unreliable.

Cheers,
Lorenzo

---

From: Chris Grundemann <[email-masked]>
Date: Wed, 31 Jul 2013 13:29:13 +0000

Thanks! I assume we disagree, but my quick thoughts anyway:

>* It only supports choosing one lease in a given transaction, and not

That's actually a feature for HIPnet, not a bug. In the case where a CPE
is connected to two (or more) HIPnet routers (due to arbitrary topology),
it uses only one. For the routers themselves, we use the "Link ID"
approach to route multiple distinct prefixes in the home
(https://tools.ietf.org/html/draft-grundemann-hipnet-00#section-5.3) - You
might call this a hack, I think it's a reliable, and extensible, solution.

>* It's not suited to supporting arbitrary topologies because it only

When combined with "up detection" (the lack of an arbitrary "Internet/WAN"
port, e.g: 
https://tools.ietf.org/html/draft-grundemann-hipnet-00#section-4.2) to
reduce any/all arbitrary topology to a hierarchy (even if only for address
provisioning) I don't see this as a problem.

>* It's not suited to supporting dynamic topologies. Information received
>reconfiguration, and even that doesn't work if the DHCPv6 server crashes
>or is unplugged.

True, but what percentage of actual residential broadband (or even SOHO)
subscribers are changing their network topology (from a router, not client
device, perspective) anywhere near often? I believe the answer is very
small. Most home networks are built and quickly forgotten in my
experience, often for years (adding a new router is not a problem with
HIPnet's use of DHCP).

>hackiness and reliability, but the end result is likely to remain hacky
>and unreliable.

Thanks again for the quick response, your feedback is always very helpful.

Cheers,
~Chris

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 31 Jul 2013 15:32:06 +0200

> Thanks! I assume we disagree, but my quick thoughts anyway:

Yes, and I thought we had already had this conversation before.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 31 Jul 2013 15:37:01 +0200

> Yes, and I thought we had already had this conversation before.

To expand on that: I thought your question was about general usage of DHCP
in the homenet. I didn't think you wanted to comment on how hipnet attempts
to solves those problems and how well it succeeds; we've already had that
conversation before (e.g., at the homenet session in IETF 86) and if the
documents have not changed since then, then there's likely not much point
in having it again.

---

From: Chris Grundemann <[email-masked]>
Date: Wed, 31 Jul 2013 13:42:01 +0000

>Yes, and I thought we had already had this conversation before.

Perhaps, apologies if that was all a re-hash, I was triggered by the
statement that clients choosing a single DHCP server was a bad thing,
since I consider it a strength. In any case, thanks again for going
through this one more time.

---

From: Chris Grundemann <[email-masked]>
Date: Wed, 31 Jul 2013 13:44:23 +0000

On 31/Jul/13 15:37 GMT+02:00, "Lorenzo Colitti" <[email-masked]> wrote:

>To expand on that: I thought your question was about general usage of
>DHCP in the homenet. I didn't think you wanted to comment on how hipnet
>attempts to solves those problems and how well it succeeds; we've already
>had that conversation before (e.g.,
> at the homenet session in IETF 86) and if the documents have not changed
>since then, then there's likely not much point in having it again.

Fair enough. But I have also found a LOT of misconceptions about HIPnet
being spread and so I may be over-eager to spread clarity to the passive
observers. Also, one of the primary intentions of HIPnet is to leverage
DHCP as a solution in the homenet, so I likely confuse the two topics.