RE: [dhcwg] ID's: DHCP Discovery Extensions / Interface Informati on Option

["Kostur, Andre" <[e-mail]>]

Regarding: DHCP Interface Information Option

- According to RFC 2131, a DHCP Server MUST NOT supply a Parameter Request
List option to a client (in OFFER, ACK, or NAK), thus a server cannot
request this option.


Regarding: DHCP Discovery Extensions

- I think there's some overlap here.  What's different between a
DHCPCONFIGURE, and a DHCPRECONFIGURE (RFC 3203) (Functionally speaking).
Both of them cause a device to acquire new configuration information.
- The DHCP Client behaviour talks about an "initially granting server", what
if the device has not yet been granted a lease from any server?
- I don't think this draft really takes into consideration the scope of
where DHCP is used.  According to the draft, a DHCPNETSCAN may be broadcast,
and should be relayed onto all other subnets.  Thus if a central DHCP server
emits 1 of these messages, that will result in it being broadcast to
_everything_ on an entire intranet.  And what about relays behind relays?
What about relays that aren't on the same subnet as the originating server?
And then there's the problem of potentially hundreds of thousands of devices
_all_ trying to DHCPREPORT back to the server within a 2 second timeframe!
- DHCPREPORT says that option 61 is to be supplied.  There is no requirement
that a client _has_ a clientID.  It also says that option 3 is to be
supplied too.  A device may not have a router defined.
- DHCPCONFIGURE is very disruptive to the network.  If all the administrator
changed was the client's DNS settings (for example), this draft requires the
client to RELEASE it's existing lease, and then assume the new settings.
It's a little foggy as to what the DHCP server is going to do when it
receives this RELEASE message.  The draft also doesn't specify what order
the RELEASE and REPORT are to be sent in.
- In section 3 you state: "To existing correct implementations of BOOTP
relay agents these new message types SHOULD be transparent."  This is
incorrect.  For DHCPNETSCAN (A server-to-client message), the bootp relay
agent is supposed to broadcast that message on all connected subnets (except
the one it was received on).  This is not the "normal" behaviour of a relay
agent.

In the abstact these are the stated goals:

   - Discovery of clients in the network
   - DHCP server redundancy
   - Server-initiated configuration of clients

DHCP server redundancy is already covered in the Failover draft.
Server-initiated configuration is covered in RFC 3203.  I'm not sure that
this draft can even do the Discovery of clients in the network, as any
device which doesn't perform DHCP would be completely invisible to this
scheme (as would any device which doesn't implement this draft).

Also in your references list, you list RFC 2131 as Authentication for DHCP
Messages.  That's RFC 3118.  Also, you make no actual reference to DHCP
Authentication within your draft.


BTW: Does this draft have implications for the zeroconf people?

> -----Original Message-----
> From: Rentschler, Markus [mailto:[e-mail]]
> Sent: Monday, November 03, 2003 2:42 AM
> To: [e-mail]
> Subject: [dhcwg] ID's: DHCP Discovery Extensions / Interface 
> Information
> Option
> 
> 
> Hello DHC-WG,
> 
> I seem to have missed the deadline for ID submission, but need some
> criticism/feedback on the issues described in the enclosed 
> drafts. Please
> read through the documents and let me know your comments.
> 
> The abstracts of these drafts are given here:
> 
> -- DHCP Discovery Extensions --
> 
>    This draft defines simple protocol enhancements to DHCP so that it
>    can be used for the following applications:
> 
>    - Discovery of clients in the network
>    - DHCP server redundancy
>    - Server-initiated configuration of clients
> 
>    The discovery mechanism described here is built upon and coexists
>    with BOOTP according to RFC 1542 and DHCP according to RFC 2131 
>    and RFC 3203.
>    It allows server-initiated communication to specific or 
> all clients 
>    in the network, using the DHCP packet format. Other DHCP servers
>    in the network can be provided with information about all
>    existing client configurations and will therefore be able to take
>    over if the main server fails.
> 
>  <<draft-rentschler-dhc-discovery-00.txt>> 
> 
> 
> 
> -- DHCP Interface Information Option --
> 
>    This draft defines a new option to inform the server about
>    the client's physical interface it is connected to.
>    This information may be used together with the relay agent 
>    information option (RFC 3046) for the purpose of topology 
>    recognition.
> 
>  <<draft-rentschler-dhc-interface-opt-00.txt>> 
> 
> 
> 
> Best Regards,
>            Markus Rentschler
> 
> 
>