Re: review of draft-ietf-node-req-bis

[Mark Smith <[e-mail]>]

Hi Thomas,

On Thu, 26 May 2011 16:21:59 -0400
Thomas Narten <[e-mail]> wrote:

> Going back to this...
> 
> Jari Arkko <[e-mail]> 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.