Subject: [dhcwg] passing relay info back to client

From: Kent Watsen <[email-masked]>
Date: Thu, 4 Jan 2018 18:34:58 +0000

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?

Thanks,

Kent

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Jan 2018 14:57:34 -0500

> 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…

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.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 4 Jan 2018 21:41:14 +0000

Hi Ted,

Thanks for the speedy reply and the pointer to RFC 6422.   Yes, that seems to do it, but looking at the IANA registry, I see that OPTION_ERP_LOCAL_DOMAIN_NAME is the only option that is supported thus far, so we'd have to add the Remote-ID and Interface-ID options if needed…

The problem I'm trying to solve is one whereby an operator has a number of devices in storage, any one of which may be retrieved and placed somewhere in their network.   The goal is for the device to bootstrap itself with the correct configuration for its given location in the network.  Normally, a device would "call home", identifying itself via its serial number (i.e., IDevID certificate), for which the NMS is preconfigured to know the device's location, and hence sends the correct configuration (for that location in the network) to the device.   However, some operators don't want to implement the backend tracking logic to know which serial number goes where; instead, they want to rely on values such as remote-id and circuit-id to identify the device's location.  In this case, the device's call home message is something like "this is my serial number, and this is where I'm located".  The NMS receiving the call home message can still verify that the device is a valid device (i.e., its serial number is allowed on the network), but rather than rely on preconfiguration to know where the device is located, it instead uses the location information passed by the device.   Both scenarios lead to the same initial configuration being passed back to the device, they only differ in the steps take to determine where the device is located.  Makes sense?

BTW, in case it's unclear, this zerotouch bootstrapping (call home) step is envisioned to be something that happens just the very first time the device boots.  The NMS would record/bind the device (serial number) to the given location, and hence does not need to be informed of its location ever again.

Thanks again,
Kent

On 1/4/18, 2:57 PM, "Ted Lemon" <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 8 Jan 2018 02:11:55 +0000

Kent:

I’m not sure I understand. Usually the correct location on the network is determined by the server by using the giaddr or Relay-Forw link-address to determine on which network segment a client is on. The remote-id and interface-id options are related to the Relay agent used, so how would the client know what to send (and sending values from where it might have been previously aren’t useful if it has been moved).

Also, letting clients provide this kind of data seems to be a potential security issue?

Also, clients are not often identified by their serial number – but by the link-layer address (see RFC 3315 section on DUIDs). Yes, there is a DUID-EN format which could include a serial number.

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Thursday, January 04, 2018 4:41 PM
To: Ted Lemon <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] passing relay info back to client

Hi Ted,

Thanks again,
Kent

---

From: kkinnear <[email-masked]>
Date: Mon, 8 Jan 2018 11:04:20 -0500

Kent,

When the NMS receives the "call home message", instead of using the
location information passed by the device (which it seems not to
have), why doesn't the NMS ask the DHCP server for the relevant
information (using the device's IP address)?  The NMS could send a
leasequery to the DHCP server, or it could query the DHCP server in a
product-dependent way.  At least some DHCP servers store the relay
agent information, and will return it if asked nicely.

Just a thought...

Kim

> On Jan 4, 2018, at 4:41 PM, Kent Watsen <[email-masked]> wrote:
> 
> Hi Ted,
>  
> On 1/4/18, 2:57 PM, "Ted Lemon" <[email-masked]> wrote:
>  
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg