Re: [dhcwg] passing relay info back to client

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 <kwatsen@juniper.net> wrote:
> 
> 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" <mellon@fugue.com> wrote:
>  
> 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.
>  
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg