Subject: [dhcwg] DHCPv4 "L2 Leasequery" thoughts.

From: "David W. Hankins" <[email-masked]>
Date: Thu, 13 Jul 2006 19:05:50 +0000

The last compelling thing I heard at the DHC WG meeting about the
reason why an "l2 Leasequery" document was necessary was that you
might not want to configure DHCP servers on every L2 DHCP relay
in existence in a given network (configuring the L3 relays is
enough of a chore...you might be able to give the L2 device a
'management address' so you can unicast to the DHCP server, but
you don't want to have to configure this on them).

So why not autodetect the presence of the DHCP server?

There are two thoughts that spring immediately to mind:

A DHCP message type which relay agents MAY respond to directly,
indicating the address(es) they intend to relay to.

A plain, vanilla, DHCPDISCOVER message transmitted on the vlan
in question.  Wait a given fixed amount of time to collect
DHCPOFFERs and select one.

These turn the conversation between the managed L2 switch and
DHCP Server into a plain, UDP Unicast, and no changes to the
leasequery are necessary.

I find this highly desirable, but I appreciate it might not fit
with design goals of the authors' and I'd like to hear their
reasoning.

Whatever the case, I would like the authors to consider allowing
the L2 device to 'switch' from the broadcast hacks being described
to unicast on the management address, if such is desired, once a
response has been received containing a server-identifier option
(for those cases where subsequent queries are going to be made,
such as after a reboot).

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 13 Jul 2006 20:55:20 +0000

> So why not autodetect the presence of the DHCP server?

In fact, why even do that?

Quoting RFC1542 section 4.1.1:

   use it consistently for all BOOTP messages it relays.  If the
   'giaddr' field contains some non-zero value, the 'giaddr' field MUST
   NOT be modified.  The relay agent MUST NOT, under any circumstances,

So, it's pretty clear to me that the L2 device that needs to
DHCPLEASEQUERY can broadcast a DHCPLEASEQUERY packet whose
giaddr is set to the L2 device's management address, and
expect a unicast response to that address (and expect an
RFC1542 relay agent to relay the packet without modifying
giaddr).

It need only make such broadcasts on the appropriate vlan to
trigger this behaviour (and the response to its 'management
interface').

So why not just rely on this RFC1542 behaviour?

Why do we need such complicated tricks and hackery?

---

From: "pavan_kurapati" <[email-masked]>
Date: Fri, 14 Jul 2006 16:12:59 +0530

Hi David,

    As already discussed in WG meeting  Access Concentrator need not always have management
IP address through the actual data network`or the management IP might not be always
reachable from DHCP server.

    Another issue we see with what you propose is described below.

    In the case layer 2 Relay Agent generate a DHCP LEASEQUERY with giaddr set to its
Management IP address, DHCP server would send a reply directly to Layer 2 Relay Agent
[destination IP set to the management IP address of Access Concentrator]. Now in this
case, when reply will reach Layer 3 Relay Agent, it would use ARP to resolve the
destination IP and then would send it to the Access Concentrator. This would mean that
AC would have to reply to the ARPs on that vlan. AC was using this vlan to bridge the
packets from Subscribers towards the L3 Relay Agent. Now, the same vlan cannot be used for
routing (replying for ARPs) for LEASEQUERY. So, what essentially this means is that
each AC should create two sets of VLANs, one for bridging traffic and other for
leasequery. This does not seems to be a scalable solution.

To create a generic solution we proposed Leasequery. We feel that the solution leasequery
provide in this case is not a hack but its a generic solution which does not assume
anything.

Thanks,
Pavan

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]]
Sent: Fri 7/14/2006 2:25 AM
To: DHC WG
Subject: Re: [dhcwg] DHCPv4 "L2 Leasequery" thoughts.

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***