[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.

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
> with the use of DHCP.

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. :)


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