Re: [dhcwg] RFC4388: Revision or new option needed?

Hi Niall,
Please find replies inline

Thanks,
Pavan

On Thu, Jun 3, 2010 at 4:23 PM, Niall O'Reilly
<Niall.oReilly+IETF@ucd.ie<Niall.oReilly%2BIETF@ucd.ie>
> wrote:

>        Hello.
>
>        I'ld like to understand what the WG's sense of the "right"
>        joint reading of RFCs 4388 and 2131 is, with regard to a use
>        case which seems to me to be unreasonably constrained.
>
>        Depending on the outcome, I may be minded to propose
>        either a revoision to RFC4388 or a new IPv4 DHCP option.
>
>        In RFC4388, the following text appears.
>        [Apologies for possible line-wrapping problems, passim]
>
> 5. Protocol Overview
>
>   In the following discussion of the DHCPLEASEQUERY message, the
>   client of the message is assumed to be an access concentrator.
>   Note that access concentrators are not the only allowed (or
>   required) consumers of the information provided by the
>   DHCPLEASEQUERY message, but they do give readers a concrete
>   feel for how the message might be used.
>
>        This seems to suggest that not only in-path devices such
>        as access concentrators and DHCP relays, but also
>        out-of-path processes, might legitimately send a
>        DHCPLEASEQUERY message.  An examples of such a process
>        might be a persistent management application, or an
>        ephemeral utility.
>
>        Now, in RFC2131, the destination of a reply to a DHCP
>        request is specified as follows.
>
>   If the 'giaddr' field in a DHCP message from a client is non-zero,
>   the server sends any return messages to the 'DHCP server' port on
>   the BOOTP relay agent whose address appears in 'giaddr'.
>
>        Unfortunately, although RFC4388 seems to admit the possibility
>        of a variety of sources for the DHCPLEASEQUERY message, the
>        lack of any text updating the above passage from RFC2131
>        constrains this variety in the following ways.
>
>        A "DHCPLEASEQUERY application" cannot usually run on the
>        same host as a DHCP server, as the 'DHCP server' port
>        typically needs to be reserved for the DHCP server process.
>
> It may sound strange as to why an application running on DHCP server would
need a leasequery mechanism to retrieve the lease data. Couldnt it retrieve
just from the lease database?
Are you going to suggest removing the constraint of adding 'giaddr' in
leasequery message (Thus indicating there was no relay agent in between)? If
so, the same condition applies when L2RAs are used and is mentioned in
draft-ietf-dhc-l2ra-extensions which also covers leasequery.


>        A "DHCPLEASEQUERY application" must run with sufficient
>        privilege to acquire access to the 'DHCP server' port.
>        This is a small nuisance for a persistent application, as
>        the usual technique is available of starting with elevated
>        privileges and retaining these only for as long as is
>        necessary to acquire the relevant system resources.
>        For an ephemeral process, such as a worker script for a
>        monitoring application, this approach is not available.
>
> I believe this requirement is rather implementation/deployment specific.

>        I'ld appreciate an indication of both
>
>   (a)  whether the WG feels that these constraints are intended
>        in RFC4388,
>
>        and
>
>   (b)  whether the WG would welcome a draft proposing one or
>        more remedies for these constraints.
>
>
>        Thanks and best regards,
>
>        Niall O'Reilly
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>