[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: simpler prefix delegation

> the amount of work required to implement PD using a DHCP based
> protocol engine versus an ICMP based protocol engine is similar. the
> benefit of reusing DHCP (ignoring the fact that its already an RFC and
> has numerous implementation) is that the cost of implementing and
> deploying all the N++ features (DNS, address assignment, SIP, ...)  is
> much lower.

There are many practical issue with using DHCPV6 for prefix delegation. 

In many cases, the source of the prefix delegation is not the same as
the source of other configuration parameters. If you read the RFC, you
have the distinct feeling that one should discover the PD server
independently of the other DHCP services. There are good reasons for
these being independent: most of the other parameters are essentially
stateless, copied from some configuration database, while PD is
stateful, possibly made up on the fly by the router managing a subnet.
Trying to shove independent assignments into a single provisioning
system is bound to cause operational problems.

Another practical issue arises when the prefix delegation server is more
than one hop away from the router requesting an assignment. The DHCP
discovery process relies on a structure of proxies, but there is no
guarantee that the proxies will end up sending the request to the
desired server. That also will cause operational problems.

> it sounds to me like the motivation here is to avoid DHCP at all
> cost. I'm certainly not a big fan of DHCP, but I'm pragmatic enough to
> see that reinventing DHCP just to get a different acronym isn't worth
> it.

If we were just speaking about packet encoding, I might agree with you.
However, we also have to consider operational issues. For example, the
RA based assignment of addresses is vastly more reliable than a DHCP
based system, because it only includes 2 parties: host and router; DHCP
requires in addition a proxy and a server, and often a network
configuration database. We have all witnessed the results: during the
typical snafu on the IETF network, IPv6 is up and running because of
automatic address configuration, while IPv4 is struggling with a
congested DHCP server.

So, yes, there is a desire to solve reliability issues that are inherent
with the use of DHCP.

-- Christian Huitema

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6