[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.

- I think we need to fix the order of occurence  some  options  that can
appear in the dhcp  messages.  I think,  the DUID  option  should  occur
before the IA option.  This makes the processing simpler.

- I didn't get, why the authentication option should be the last one.  I
feel like it should be the first one.  If the  server/client is not able
to validate the  authentication, it can straight away discard the packet
without further processing.

- Section 13 says the ways for selecting  addresses  for  assignment  in
IAs.  Assume, the server has got a direct  message from the client.  The
IP datagram source address is a site-local one.  The message is received
on the server's  interface,  which is configured with a global  address.
According to the draft, the server  should  assume that the client is on
the link  identified  by the  sitelocal  address in  datagram.  Now, the
problem   arises,  if  the  server  is  not  configured  for  allocating
site-local  address for the link.  Now, can the server assume, since the
client has sent the direct message, it is on the same link as the server
and assign it an address of global  scope,  with the same  prefix of its
received  interface.  I think, i have already raised the similar kind of
problem previously, the answer i had got was to select address of global
scope.  Then, the server  should not select the link based on the source
address.  This  is an  implementation  problem  we  faced.  FYI,  HP has
officially  released DHCPv6.  This  implementation  is based on 16th and
some  portion of 18th  version of the  draft.  This  software  is freely
available  at  http://software.hp.com/  You can  download it and tell me
your comments.

- Using DUID, how the address selection is done?

- The draft  says that, when the client  needs an  additional  temporary
address, it can include OPTION_RTA encapsulated in OPTION_IA and get the
additional one.  This means, in the same IA, any number of addresses can
be can be added and deleted.  Will it hold for normal addresses also?  I
mean, for  additional  normal  addresses,  whether the client has to use
already  existing IA to get additional  address (or) will it use a fresh
IA?  I remember that, the answer i got for this question 3-4 months back
was that the client will use fresh IA,  because,  adding  address to the
same IA will lead  complexity.  Just in curiosity, i am asking, why this
complexity was introduced for temporary addresses?  Why can't the client
can ask additional temporary addresses in a fresh IA?

- Can temporary  addresses and normal addresses can co-exist in same IA?
If yes, then, for renewal, does the client send normal  addresses  alone
in IA to the  server?  since,  the  renewal of  temporary  addresses  is
meaningless.

- I thought for decreasing the load of server, unlike DHCPv4, in DHCPv6,
the dns  updates  was moved to  client.  But, the draft  says  that, for
temporary addresses, the server has to update the DNS.  Why this feature
was included in server, instead of client?

-  Why  only  temporary  has  to be  updated  in  DNS?  why  not  normal
addresses?

- I think for  updation,  we need to define,  hostname/FQDN  option  for
this.

- How can the client  specify  the number of address  it wants?  Will it
send IA optio with 'n' number empty of IA_ADDR option?  Instead of that,
can we define  another  option  OPT_RA  similar to OPT_RTA,  that can be
encapsulated in OPT_IA?

- Section 17.1.2 says that the client collects  Advertise messages until
SOL_TIMEOUT has elapsed.  Then, RT will be  recalculated.  Now, does the
client needs to retransmit the SOLICIT  message?  If it is so, then, the
same server will reply multiple times.  But the retransmission algorithm
in Section 15 says that, it should retransmit the packet. 

- In  section  17.1.2, we need to add a  sentence,  "When the RT reached
MRT, if the one or more valid advertise  message is obtained, the client
should stop sending Advertise message and proceed further with collected
Advertise  message".  Otherwise,  since MRC and MRD are 0, this  process
will go infinetly  according to algorithm specified in Section 15.  This
is also an implementation problem we faced.

- In some place, the server should fill "server-address" with one of its
address  based on the link in which the packet is  received.  In another
place, it is said that the  server-address  field can be filled with the
address configured by the administrator.  What is the standard procedure
to be followed?

- In Advertise,  should the server assign all the addresses asked by the
client?  (or) only few of them?

- Till what  time,  these  OFFERED  addresses  are  preserved  for those
clients to assign?

- If the server has fewer  addresses than the client has asked, will the
server assign fewer addresses or send AddrUnavail?

- The draft says that the renew  message can be used for checking up the
validity  of  the  other  configuration  parameters.  For  checking  the
validity  of them, will the client  send the option  codes in ORO option
(or) send the parameters in their respective options?

- Should release/decline of addresses be done for IA as whole?  (or) Can
few addresses be relased from an IA? (partial release)

- Assuming the client is sending  multiple IAs for renewing,  the server
finds that one particular IA is not found in the client  bindings,  will
it renews the remaining IAs? (or) will it send NoBinding error?

- What will the client do, for the multiple IAs sent for renew, only one
IA is missing in the reply?

- Can you explain the differnce between, "configuration  information are
not valid" and "configuration information does not match".  In the first
case, for Confirm  message  ConfNoMatch is sent and for the next one, it
is  sending  SUCCESS.  The draft says that for  ConfNoMatch,  the client
should  send renew  message.  If the  configuration  parameters  are not
matching, then what is the use of sending renew message?

- For the cases like, "conf parameters are not valid", "conf  parameters
does not match" and  "prefix  does not match",  what will the server do,
for the release message?  What will the server do? if (i) all, (ii) only
few  addresses  are invalid.  Will the server  release the address which
are valid?

- Section  21.6.5.5 says that, if the client is not able to validate the
authentication  for the REPLY  message,  then it should  start  with the
SOLICIT.  I feel that this is inefficient,  instead, it can try the next
available server which has sent the advertise message.

- In the previous  versions, we have  Retransmission  Parameter  option.
Why it was removed?

- Some useful options were defined in DHCPv6 extension draft.  When will
those options be included in this draft?

I have found some typos in the draft.

- In section 7.3, for  reconfigure  message, the client should  intiate,
Renew/Reply not the Request/Reply

- In 19.2, it is  saying  that, for  Inform  message,  all the IAs to be
included.  This a simple cut-paste problem.

- 19.3.4 says, "The client uses the same  variables  and  retransmission
algorithm  as it does with  Rebind  or  Information....".  It  should be
"Renew or Information..."

- In 22.14, the server address field in Server Unicast Option is missing.

- In 22.19, User class option  message  format  looks messy,  because of
some sentences in between.

Regards
Vijay

-- 
____Vijay_Bhaskar_A_K____
________HP_ESDI__________
___Ph:_91_080_2051424____
____Telnet:_847_1424_____
___Pager:_9624_371137____

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