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
On Wed, Nov 14, 2012 at 8:31 AM, Simon Kelley <si...@thekelleys.org.uk>wrote:
> 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.
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
