Re: [dhcwg] Comments on 22 rev of the draft

> I disagree that DHCPv4 requires that a server explicitly reserve an address 
> it has offered to a client.  From RFC2131:
> 
>    3.1 Client-server interaction - allocating a network address
> 
>     [...]
> 
>     2. Each server may respond with a DHCPOFFER message that includes an
>        available network address in the 'yiaddr' field (and other
>        configuration parameters in DHCP options).  Servers need not
>                                                    ^^^^^^^^^^^^^^^^
>        reserve the offered network address, although the protocol will
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        work more efficiently if the server avoids allocating the offered
>        network address to another client.  When allocating a new address,
>        servers SHOULD check that the offered network address is not
>        already in use; e.g., the server may probe the offered address
>        with an ICMP Echo Request.  Servers SHOULD be implemented so that
>        network administrators MAY choose to disable probes of newly
>        allocated addresses.  The server transmits the DHCPOFFER message
>        to the client, using the BOOTP relay agent if necessary.

I agree  that it does not say the  server  must  reserve  address  while
offering.  But it says  that  if it  does,  then  the  protocol  is more
efficient.  These things are  practised  and went well in DHCPv4.  Then,
what is the harm in making  this as  mandatory  in  DHCPv6.  I feel that
best  practises  in V4 should be mandated in V6.  Anyhow,  the client is
going to wait collecting Advertise message.  If the server processes the
client  requirements  and allocate  necessary  options to the clients in
advetise  message, then the response time for the client's  REQUEST will
be very good,  thus  increasing  the  efficiency  of the whole  protocol
itself.  In the realtime situation, most of the solicit messages will be
followed by request  message.  If it doesn't send request also, there is
a time knob for these OFFERED addresses, once it expires, it will be put
in general pool for allocation to other clients.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg