Subject: RE: simpler prefix delegation

From: "Christian Huitema" <[email-masked]>
Date: Sun, 21 Mar 2004 12:11:50 -0800

> 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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Sun, 21 Mar 2004 21:11:35 +0000

> automatic address configuration, while IPv4 is struggling with a

DHCP PD can very well only include two parties. the requesting router
and the delegating router. no additional proxies or servers are
required. by server I presume you mean a separate box from the
first-hop router, and not the DHCP PD process running in the
delegating router. as you well know the RA server in the first-hop
router may as well go down as the PD process.

the delegating router could get prefix information from a third party
server like AAA or DHCP but that is not required for the operation of
the protocol. if the ISP would want to authenticate the user using e.g
radius and the prefix information can be included in the AAA messages
so not additional servers are needed.

> So, yes, there is a desire to solve reliability issues that are inherent

since prefix delegation is stateful it might be less reliable than a
stateless protocol. unless there is a proposal for how to do stateless
prefix delegation, then substituting DHCP for ICMP isn't going to make
the slightest difference for reliability.

I know it is in good tradition of this working group to reopen and
reiterate every discussion ever had every nine months or so. isn't it
about time we close this working group if there isn't anything new to
work on? or at least reopen some interesting discussions. I still
think the address should be 64 bits long. :)

/ot