Re: [dhcwg] passing relay info back to client

[Ted Lemon <[e-mail]>]

On Jan 4, 2018, at 1:34 PM, Kent Watsen <[e-mail]> wrote:
> In support for draft-ietf-netconf-zerotouch, I'm wondering about what relay information the DHCP client may learn in a DHCP response.  Specifically, it would be helpful for deployments that do not wish to track the movement of specific devices (serial numbers) if the device (via its DHCP client) could learn the relay information used by the DHCP Server to identify it.  However, sadly, I'm beginning to think that this is not possible...
>  
> For DHCPv4, RFC 3046 Section 2.1 says:
>  
>    The Relay Agent Information option echoed by a server MUST be removed
>    by either the relay agent or the trusted downstream network element
>    which added it when forwarding a server-to-client response back to
>    the client.
>  
> For DHCPv6, RFC 3315 Section 20.1 says:
>  
>    The relay agent processes any options included in the Relay-reply
>    message in addition to the Relay Message option, and then discards
>    those options.
>  
> Is this the end of the story, or am I overlooking something?  Do implementations ever pass the relay info back to the client anyway?   Would there be any interest in changing this behavior in DHCP so as to better support zerotouch bootstrapping scenarios?


RFC 6422 addresses this issue for DHCPv6.   There's no solution for DHCPv4.   In general, we don't want the relay to be adding options to the packet on the way to the client, so it would have to be special-case behavior.   There's no reason why something like RFC 6422 couldn't be done for DHCPv4—it's just that it's a legacy protocol, so we aren't doing work on it.

That said, can you talk about the actual problem you're trying to solve here?   What you said you want to do doesn't actually make sense to me, so either I'm missing something, or you're thinking of doing something with DHCP that doesn't actually make sense in the greater context of DHCP.