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

[Ralph Droms <[e-mail]>]

At 11:08 PM 1/18/2002 +0530, Vijay Bhaskar A K wrote:
>Bernie,
>
>See my comments prefixed by VB2>
>
>~ Vijay
>
> > Vijay, see BV2> comments.
> >
> > - Bernie
> >
> > -----Original Message-----
> > From: Vijay Bhaskar A K [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 4:35 AM
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [dhcwg] Comments on 22 rev of the draft
> >
> >
> > See my comments inline prefixed by VB>
> >
> > ~Vijay
> >
> > > Let me try to answer these based on my understanding/view of -22.
> > >
> > > See below.
> > >
> > > - Bernie
> > >
> > > -----Original Message-----
> > > From: Vijay Bhaskar A K [mailto:[e-mail]]
> > > Sent: Wednesday, January 16, 2002 1:05 PM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: [dhcwg] Comments on 22 rev of the draft
> > >
> > >
> > > I had gone through the latest rev of DHCPv6  draft.  Sorry for the delay
> > > in telling the comments.
> > >
>[...]
> > > - Till what  time,  these  OFFERED  addresses  are  preserved  for those
> > > clients to assign?
> > >
> > > BV> My opinion is that the ADVERTISED addresses are just a possible 
> set of
> > > addresses the client will get and may not be the exact addresses. The 
> client
> > > must wait until the Reply to the Request before it knows which 
> addresses it
> > > got and before it does Duplicate Address Detection. The ADVERTISE should
> > > include all of the parameters the client is likely to receive in the 
> Reply,
> > > but they are just possible values and not the actual values.
> >
> > VB> What i am  asking  is, in V4,  there  is a  concept  called  OFFERED
> > addresses, which will be reserved to a client.  The server reserves that
> > addresses for the some predefined  time.  At the expiration of the time,
> > if the client has not sent the  request,  it will be  allocated  to some
> > other  clients.

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 think,  if we  follow  the  same  policy,  it will be
> > better.  Assume, a client  sends a SOLICIT and the server  replies  with
> > ADVERTISE  with some  addresses.  Before the client sending the Request,
> > if some  other  client  requests  for the  addresses,  with the  current
> > mechanism,  the server will assign the  addresses to new client.  It may
> > lead to server to send  AddrUnavail  to the first  client, if the server
> > has only  limited  number  of  addresses.  It will  lead to  unnecessary
> > packet transactions.
> >
> > BV2> I don't agree. It is much better if the server can just send something
> > out and not have to do anything to remember it. With IPv6, what's the 
> likelyhood
> > that an address won't be available - we have 2^64 addresses on each prefix!
> >
> > BV2> What I view the ADVERTISE message to be is for the server to say I am
> > willing to give you this stuff [assuming it is avaiable] but that I haven't
> > given you the EXACT stuff you will get (since that happens in the Reply to
> > the Request).
> >
> > BV2> BUT please note that this really is up to each SERVER to do what it
> > wants. A SERVER can chose to ADVERTISE real stuff and "reserve" it for some
> > period of time (and that is a SERVER implementation issue). In my server,
> > I might chose that time to be 0 seconds. In your server, you can set it to
> > 1 hour. The client can't do anything with ADVERTISEd information other than
> > make a decision based on which ADVERTISE it wants to accept (assuming 
> it gets
> > multiple). In any case, the information from the Reply is what it must 
> install.
> > So, this is purely a server implementation issue.
>
>VB2> Yes. I agree that this is purely an implementation issue.


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