Hi Thomas, On Thu, 26 May 2011 16:21:59 -0400 Thomas Narten <nar...@us.ibm.com> wrote:
> Going back to this... > > Jari Arkko <jari.ar...@piuha.net> writes: > <snip> > > New text: > > 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 > > Because a single DHCP server can support devices on multiple links, > it is not necessary that every router support DHCPv6 directly. > However, in order to support DHCPv6 servers on other links, routers > SHOULD support relay agent functionality of DHCPv6 [RFC3315]. > Routers MAY support full [RFC3315] or stateless [RFC4862] DHCPv6 > server functionality as well. > > I'm on the fence wrt MAY/SHOULD on the recommendation above. I don't > think every router needs to support DHCP, hence the MAY. But SHOULD is > also not a MUST, so I'd be OK with SHOULD. > > Indeed, where one arguably should have a MUST is in relay agent > functionality. SHould I elevate it? > > Thoughts? > I think relay should be a MUST. I want to see IPv6 achieve the same level of autoconfiguration that previous protocols like Appletalk and IPX achieved, which includes automated application/service parameter configuration. If the application/service parameter source is off link (i.e. an off-link DHCPv6 server), then currently the only way for those options to passed opaquely to end-nodes via a router is via a DHCPv6 relay capability. I've recently realised "route constraint" is currently a problem in an SP environment. As an SP, you want to automate as much as possible the configuration of all the services you provide to customers, such as providing DNS, SIP, NTP etc. parameters. If you add another service, and therefore add another DHCPv6 option to be provided to end-nodes, you need to have that new option get to the end-nodes for those that are interested in it, meaning that new option needs to "traverse" the CPE. However, currently the CPE RFC only says that the LAN interface should implement a DHCPv6 server, and provide options to the end-nodes using the options that the CPE has leaned via the DHCPv6-PD transaction on the WAN interface. This means that if the CPE doesn't support the new DHCPv6 option for the new service you've deployed, then the end-nodes can't be provided with that DHCPv6 option despite them supporting it. In a market where customers own and operate the CPE, the only DHCPv6 options a SP can therefore rely on being supported in CPE is likely to be no more than DNS addresses. For markets where the CPE is owned and operated by the SP, it still means a firmware update, supporting the new DHCPv6 option, has to be deployed to all CPE before the application can be deployed. In other words, a device in the network now constrains the deployment of a new application on the end-nodes. I think that situation is actually violating one of the most valuable principles of the Internet - that new application deployment doesn't have a dependency on the deployment of new capabilities in the network. So I think a DHCPv6 relay in routers should be a MUST. Somewhat off topic but related, I'm also thinking there should be a DHCPv6 option to convey one or more DHCPv6 server addresses that is learned by CPE during the DHCPv6-PD transaction, with the DHCPv6 server then used for a DHCPv6 relay operating on the LAN interface. An SP can then have the CPE LAN interface DHCPv6 relays pointing to a nominated off-link DHCPv6 server (the default without this new option could be the DHCPv6(-PD) server), which would allow CPE unsupported DHCPv6 options to transparently traverse the CPE, directly reaching the end-nodes. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------