Subject: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).

From: Jim Gettys <[email-masked]>
Date: Tue, 13 Nov 2012 14:04:38 -0500

I've been watching the discussion about recursive DHCPv6-PD with more than
a little discomfort; I did not want to throw this bomb until the issue had
been discussed in depth (as prefix delegation is a problem we must solve).

The hardest problem I've ever had to debug in my home network (by far) was
a rogue DHCP server, which occasionally would give me a bad address.  It
was located on a tiny, size of a deck of cards, VOIP box I was no longer
using. It being on a slow processor, my main DHCP server responded much
faster, so it was a very intermittent failure, solved only by perusal of
logs, wireshark, lookup into the MAC address to vendor assignments, and
then guessing which device in my house it might be.  This is well beyond
the usual home user, at the edge of what I am capable of (I'm primarily a
designer of application network protocols, not a true 'friend of the
packet').  I dare say that most ISP's could not have debugged the problem,
even if they had access to my network (nor do I want them to have to have
access).

So the recursive DHCP-PD scheme strikes me as something possibly very
fragile. I really, really don't want to repeat the experience I had with
having extra DHCP servers, and I would guess few ISP's do either.

It seems to me much more robust to flood the key configuration information
(prefixes, DNS, NTP, and the like) via a protocol that is really designed
for the job (whether specifically for configuration, ie. ahcp
http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/, or via the hacks
on routing protocols like Ari has done with OSPF).

What is more, this configuration information should be revocable; we don't
want one upstream provider to induce problems in service to the other.

I think I goal for Homenet should be/must be robustness, and "hotplug".
 You should be able to plug in new devices and have them "just work"; that
includes networks, whether ISP networks or not.  Telling a home user to
replug all their devices isn't an option. That I often have to do this with
my cable modem and home router (and then possibly clients), I see as a
failure already happening.

We should judge alternative proposals by this touchstone.
                              - Jim

---

From: Simon Kelley <[email-masked]>
Date: Tue, 13 Nov 2012 20:19:22 +0000

> on routing protocols like Ari has done with OSPF).

Given that hosts are going to want to talk RA or DHCPv6, at least 
initially, one option down this route has the flood include the unicast 
address of a single, centralised DHCPv6 server, and routers run 
DHCP-relay agents which forward to that address. That gives you DHCPv6 
functionality without recursive-PD complications. It also eliminates the 
problems of distributing the available prefixes as they traverse PD 
chains. The one-and-only DHCP server knows about all the prefixes 
delegated from the ISP and the relays know which particular prefix has 
been given to the local router by the routing protocol or AHCP.

Simon.

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 13 Nov 2012 15:48:44 -0500

On Tue, Nov 13, 2012 at 3:19 PM, Simon Kelley <[email-masked]>wrote:

>> http://www.pps.univ-paris-**diderot.fr/~jch/software/ahcp/<http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/>
>> **, or via the hacks
> address of a single, centralised DHCPv6 server, and routers run DHCP-relay
> agents which forward to that address. That gives you DHCPv6 functionality
> without recursive-PD complications. It also eliminates the problems of
> distributing the available prefixes as they traverse PD chains. The
> one-and-only DHCP server knows about all the prefixes delegated from the
> ISP and the relays know which particular prefix has been given to the local
> router by the routing protocol or AHCP.
>

I assume in your model, hosts on the various subnets will then have access
to a centralized DHCPv6 server and other hosts can still use SLACC (which
is connected to ::/64s on the local attached router's interface).  Would
the internal routers also get the ::/64 prefixes from the central DHCPv6
server (assume so)?  If yes, would they grab a PD (with hint) for a range
large enough to cover all of its' interfaces?

regards,

Victor K

>
> Simon.
>
>
> ______________________________**_________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>

---

From: Simon Kelley <[email-masked]>
Date: Tue, 13 Nov 2012 21:01:09 +0000

On 13/11/12 20:48, Victor Kuarsingh wrote:
> On Tue, Nov 13, 2012 at 3:19 PM, Simon Kelley<[email-masked]>wrote:

> large enough to cover all of its' interfaces?

This part of the scheme is still wooly in the extreme, but my thinking 
is that DHCP-PD would _not_ be involved. The centralized server would be 
a DHCP-PD _client_ and get a set of prefixes from the ISP(s), but the 
distribution of those prefixes over the routers would be a side-effect 
of whatever configuration system generates the routing tables and 
spanning-tree for the homenet. I think I understood the OSPF guys at 
IETF as saying that OSPF could do this, and I think I understand Dave as 
saying that AHCP can do it. More details of either or both schemes would 
be very interesting to hear.

Cheers,

Simon.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Nov 2012 15:03:15 -0600

On Nov 13, 2012, at 1:04 PM, Jim Gettys <[email-masked]> wrote:
> So the recursive DHCP-PD scheme strikes me as something possibly very fragile. I really, really don't want to repeat the experience I had with having extra DHCP servers, and I would guess few ISP's do either.

It seems to me that using bad implementations as a guideline is always a bad idea.   We've had sites go down as a result of OSPF routing mistakes, so it's not the case that any of the alternatives we are talking about are immune to bad implementations.

---

From: Teco Boot <[email-masked]>
Date: Wed, 14 Nov 2012 13:08:19 +0100

Op 13 nov. 2012, om 21:19 heeft Simon Kelley het volgende geschreven:

> Given that hosts are going to want to talk RA or DHCPv6, at least initially, one option down this route has the flood include the unicast address of a single, centralised DHCPv6 server, and routers run DHCP-relay agents which forward to that address. That gives you DHCPv6 functionality without recursive-PD complications. It also eliminates the problems of distributing the available prefixes as they traverse PD chains.
Right.

> The one-and-only DHCP server knows about all the prefixes delegated from the ISP and the relays know which particular prefix has been given to the local router by the routing protocol or AHCP.
I don't like a single DHCP server for multi-homed sites. This introduces unneeded complexity, it needs merging of information from multiple sources. This is completely incompatible with what MIF is doing (multiple provisioning domains). It also introduces an unneeded single point of failure. Multi-homing could be used for redundancy. Let's use a DHCP server for each ISP.

In cases where a single CPE router connects to multiple ISPs, it can take two approaches: running multiple DHCP server instances, one for each ISP. Or perform the problematic integration.

BRDP takes the "per provisioning domain" approach, where each provisioning domain is presented with a border router address (generated form provided prefix), with prefix length. Problem solved :-). 

Teco

> 
> Simon.
> 
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Simon Kelley <[email-masked]>
Date: Wed, 14 Nov 2012 13:31:05 +0000

On 14/11/12 12:08, Teco Boot wrote:

> 
>> The one-and-only DHCP server knows about all the prefixes delegated
>> from the ISP and the relays know which particular prefix has been
>> given to the local router by the routing protocol or AHCP.
> I don't like a single DHCP server for multi-homed sites. This
> introduces unneeded complexity, it needs merging of information from
> multiple sources. This is completely incompatible with what MIF is
> doing (multiple provisioning domains). It also introduces an unneeded
> single point of failure. Multi-homing could be used for redundancy.
> Let's use a DHCP server for each ISP.
> 
> In cases where a single CPE router connects to multiple ISPs, it can
> take two approaches: running multiple DHCP server instances, one for
> each ISP. Or perform the problematic integration.
> 
> BRDP takes the "per provisioning domain" approach, where each
> provisioning domain is presented with a border router address
> (generated form provided prefix), with prefix length. Problem solved
> :-).

OK. This raises some questions about DHCPv6 to which I don't know the
answers. I hope Ted or someone else who was involved in the standard can
answer.

Simplest case first. Client and server on same link (in the RFC3315
definition of link) the server has an interface on the link which has
multiple addresses with different prefixes, and it is configured to
assign addresses on each of those prefixes. The client is unconfigured
except for a link-local address. How does the client create a SOLICIT
message which causes the server to reply with an ADVERTISE which offers
the client an address with each of the prefixes ? The client doesn't
know how many prefixes are available.

Next case. The same as above but the SOLICIT transits via a relay. The
relay can only insert one link address in the encapsulation, does the
server have to know which prefixes share links so that it can determine
which other prefixes are on the same link and reduce the problem to the
case above?

Next case. This speaks to Teco's suggestion. The same link with multiple
prefixes, directly connected to servers, but now each prefix is handled
by a different DHCP server. The client multicasts SOLICIT to all the
DHCP servers. How does it collect all the addresses for different prefixes?

Final case. Multiple DHCP server, all behind a relay. The relay has to
be configured to unicast to each server in turn?

Knowing the answers to these questions would be really useful at this point.

Simon.

---

From: Jim Gettys <[email-masked]>
Date: Wed, 14 Nov 2012 11:24:41 -0500

Please, let's not OD on DHCP in this thread: while I was making a point
about DHCP, I was really making a more general point about robustness in
homenet, and how to judge various proposals, more than specifically
attacking recursive DHCP-PD as a concept.

Similarly, I think as another goal we have to accept easy debuggability as
a goal.  We need to know if a router is expected to function, and you
should be able to easily see if the router is functioning *and* if can talk
to its border routers and the rest of the Internet.  One of the things I
like about CeroWrt is that I can *always* talk to the router and from there
I have a chance to figure out if it is able to talk to the rest of the home
network, and the world (e.g. by seeing that I've got an IPv6 network
delegation).  Today, since we have to presume that you need a IPv4 address,
this implies running a DHCP server on each router: in the long run, it's
less than clear to me that this is desirable.  But one way or the other,
I've got to be able to connect and talk to the router to be able to debug
it, preferably from both upstream and downstream directions.  The CeroWrt
router I'm debugging doesn't "fate share" with other routers to the point
that you have no place to stand initially.

So I'd expand my list of how to judge proposals to the configuration
distribution problem to be:
    1) robustness
    2) hotplug
    3) debuggability

                                  - Jim

---

From: Simon Kelley <[email-masked]>
Date: Wed, 14 Nov 2012 16:27:58 +0000

On 14/11/12 16:24, Jim Gettys wrote:
> Similarly, I think as another goal we have to accept easy debuggability
> as a goal.  We need to know if a router is expected to function, and you
> should be able to easily see if the router is functioning *and* if can
> talk to its border routers and the rest of the Internet.  One of the
> things I like about CeroWrt is that I can *always* talk to the router
> and from there I have a chance to figure out if it is able to talk to
> the rest of the home network, and the world (e.g. by seeing that I've
> got an IPv6 network delegation).  Today, since we have to presume that
> you need a IPv4 address, this implies running a DHCP server on each
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> router: in the long run, it's less than clear to me that this is
> desirable.  But one way or the other, I've got to be able to connect and
> talk to the router to be able to debug it, preferably from both upstream
> and downstream directions.  The CeroWrt router I'm debugging doesn't
> "fate share" with other routers to the point that you have no place to
> stand initially.
> 
> 

I agree with this, except the underlined section: DHCP-relay is a
standard technique for DHCPv4.

Simon.