Subject: RE: [dhcwg] An enhancement for DHCPINFORM?

From: "Kostur, Andre" <[email-masked]>
Date: Fri, 8 Apr 2005 08:34:54 -0700

> > 4) How much effort is it going to be on the part of the DHCP Relay 
> > implementations to have to remember the source port of the 
> request, and 
> > to match up the response to the right request.  Recall that 
> what would 
> > end up happening (potentially) is that your client application may 
> > broadcast the request (from say port 2000).  This gets 
> picked up by a 
> > relay, and it unicasts to the DHCP server (likely a 
> different port than 
> > 2000, probably either 67 or 68).  The DHCP server would 
> then see this 
> > bit set and would be "forced" to respond to the source port (again: 
> > either 67 or 68, depending on your relay implmenetation.  Most 
> > signficantly it will probably not be 2000).  Then the relay 
> would need 
> > to have enough memory to recall that this response is 
> associated with a 
> > certain request and look up what the original port number was.  In 
> > addition, it would have to remember this port for a time 
> since the relay 
> > may be relaying to multiple DHCP services and you would want all 
> > potential responses to be forwarded back to the client.
> > 
> 
> I think it would be fine to specify that the flag is only 
> valid in DHCP 
> requests which are unicast directly to a DHCP server, so 
> there should be 
> no implications for relay agents.

As you have mentioned in your response to my other points, your application
may not know where your DHCP server is (your application has no access to
the original lease data), so it may have no alternative than to broadcast
your INFORM.  So your INFORMs would end up passing through a relay, and
we're still in the same boat.

Also in certain environments, you may not be able to unicast to the DHCP
server directly, you may be required to pass through a relay to reach the
server.  Through various feats of handwaving, your DHCP client may not ever
know who the DHCP server really is....
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg