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

[Vijay Bhaskar A K <[e-mail]>]

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.
> > 
> > - 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.
> > 
> > BV> I think this would be good to say that a client MUST place the DUID option in a mesage before any IA options. 
> > 
> > - 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.
> > 
> > BV> I too wouldn't mind having this earlier. It makes it easier to validate messages since one doesn't have to process all of the options (or at least parse to some extent all of the options) before one can authenticate the message. But, I would call this a SHOULD not a MUST.
> 
> VB> I would like to call this MUST rather  than  SHOULD,  because,  this
> authentication  model of DHCP came only for avoiding  DoS  attacks.  The
> server should not waste its time in processing these spurious packets.
> 
> > 
> > - 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.
> > 
> > BV> Section 13 tells how to determine the *LINK* the client is on. Once
> > that has been done, you assign addresses based on the prefixes that the
> > server has configured for that *LINK*. If the source address for the
> > DHCP message was a link local, the server knows that it can't have come
> > from anywhere but that link (since link-local are only valid locally).
> > But this only determines the LINK for the client; not the addresses.
> 
> VB> Assume the  scenario  where the server and client  are in same link.
> The  configuration  of server's  interface  and client  interface  is as
> follows.
> 
> server lan0   -  fe80::260:b0ff:fec1:bb6b (A link local address)
> server lan0:1 -  3ffe::12 (A global address)
> client lan0   -  fe80::210:83ff:fe18:886f (A link local address)
> client lan0:1 -  fec0::1234:27 (A site local address)
> 
> server lan0 and client's lan0 are in same link.  Now the client  decides
> to get an IP  address  from  dhcp  server.  So, it puts  the site  local
> address (lan0:1 addr) in the IP datagram src address field and sends the
> SOLICIT  message.  Assume, the server is  configured  to  allocate  only
> global address of prefix 3ffe::/64 for that link.  But, according to the
> draft,  it finds  out  that  the  message  comes  from  fec0::1234:27/64
> network, finds out it is not supposed to serve that network and hence it
> does not send  advertise.  What i feel  is,  since  the  allocation  for
> normal addresses are dictated by server's policy, let the server dictate
> completely.  let it not to give any preference to client's wish.  In the
> above  situation,  if the server is not  noticing  the src address in IP
> datagram  of the  client, it can find out that the client is on the same
> link as the server, since it is a direct message.  Thus, it can allocate
> allocate address of prefix 3ffe::/64.  Since the SOLICIT message is sent
> to All DHCP Agents  Address, if the server  receives the client  message
> directly,  then, the client is in the same link.  Thus, the  decision of
> the link based on the IP  datagram  src  address of the client is not at
> all necessary.
> 
> BV2> Again, all the server does is use the address to determine the LINK.
> So, the server needs to know about the site local prefix being active on
> the link but that's all. If the server fails to find the prefix for the
> address, it can either drop the request or it could simply assume it must
> have come from the LINKs associated with the interface the packet was
> received on. So, it is happy.
> 
> Note that the client really should be using the link local address UNLESS
> it is unicasting to a server (in which case it must use an address of
> sufficient scope valid for the server to send replies). The All DHCP
> Agents address is link scoped, so the source address only needs to be
> linked scoped as well.
> 
> So, I don't see any issues here. Or am I failing to understand your concern?

VB2> What i mean is, for  finding  the  link,  server  should  not trust
client.  It  knows  the  link  where it is  received.  Based  on its own
address  in the link, it should  allocate  address  to the  client.  The
client may not be  knowing  where it is.  Sometimes,  what it has may be
wrong.  So, the src address in IP datagram may show wrong information.

VB2> Assume,  a client is moving from the 3ffe::/64 network to 5ffe::/64
network.  As per the draft, it will the  confirm  message.  16.2.2  says
that, the server will just compare the binding info it's having with the
one in confirm  message.  I think the server MUST check the prefix also.
It must  check  whether  the  addresses  in the IA are  having  the same
prefixes of the link in which the client is  connected  to.  I think, no
where in the draft, the draft is not dealing with the prefix  comparison
of the link and IA  addresses.  So, in this  case,  the  server  sends a
positive  reply.  The client wont get it,  because, it does have a valid
address to receive it.

VB2> After some time, if it requires another address, it will send a new
request with the src address with 3ffe::/64  prefix and hence the server
allocates the address with 3ffe::/64  prefix for the 5ffe::/64  network.
I think the neat and clean way of client  asking for the  addresses in a
particular  prefix,  is sending  through  an option,  similar  to subnet
selection  option  (RFC 3011).  I can include the text for this  option.
This is one of the  option,  i have  forgetten  to tell in the  previous
mail.

> 
> > 
> > - Using DUID, how the address selection is done?
> > 
> > BV> I don't understand what you are asking here. 
> > 
> > - 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?
> > 
> > BV> We do NOT want IA explosion. Ideally, a client should be able to use
> > the same IA forever under "normal" cases. A IA can have one or many
> > addresses, addresses will come and go. Server policy dictates the non-
> > temporary addresses assigned to a client. Client policy dictates the
> > temporary address needs - hence the client must have a way to say
> > "give me more". For example, if a client is running two applications that
> > each want unique temporary addresses, it has to request those from the
> > server. Later, when a third application starts, the client will need
> > another address.
> > 
> > - 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.
> > 
> > BV> YES the can both be in the SAME IA. That is the intention.
> > 
> > - 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?
> > 
> > BV> What we say in section 14 is:
> > 
> >    The server MAY update the DNS for a temporary address as described in
> >    section 4 of RFC3041, and MUST NOT update the DNS in any other way
> >    for a temporary address.
> > 
> > BV> This all depends how DDNS is handled with DHCPv6 and who is doing the
> > updates. We just wanted to be clear that if the server was doing DDNS
> > updates for the client, is must adhere to the requirements of RFC 3041
> > in doing them!!
> > 
> > -  Why  only  temporary  has  to be  updated  in  DNS?  why  not  normal
> > addresses?
> > 
> > BV> See answer to previous question. DDNS updates are still TBD. Likely
> > the DHCPv4 FQDN option will be used (changing the A processing to reflect
> > AAAA processing and using the DUID for the client identification).
> > 
> > - I think for  updation,  we need to define,  hostname/FQDN  option  for
> > this.
> > 
> > BV> Yes, we will need 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?
> > 
> > BV> The client can't specify how many non-temporary addresses it wants.
> > This is controlled by the server. The client *CAN* use multiple IAs and
> > if the server policy allows, that can easily be used to give the clients
> > LOTS of addresses (one set per 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. 
> > 
> > BV> The client waits SOL_TIMEOUT but it does not retransmit the Solicit
> > if it has received at least one Advertise. Retransmit Solicit only if no
> > Advertise messages are received.
> 
> VB> The Algorithm in section 15 says that, it should  retransmit  at the
> expiration  on RT.  The  variation  for  SOLICIT  on this  algorithm  in
> 17.1.2, does not say  anything  about this.  So, it is better to add the
> statement  you have stated above, in the draft also for better  clarity.
> Otherwise, it is misleading.
> 
> BV2> I will review the text again to see if this was not clear.
> 
> > 
> > - 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.
> > 
> > BV> Haven't studied this issue.
> > 
> > - 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?
> > 
> > BV> We probably should clean up the text to be consistent. I think the
> > answer is use configured address if so configured for that LINK, otherwise
> > use one of the LINK interface addresses.
> > 
> > - In Advertise,  should the server assign all the addresses asked by the
> > client?  (or) only few of them?
> > 
> > BV> It depends on the server's policies.
> > 
> > - 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 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.

> 
> > 
> > - If the server has fewer  addresses than the client has asked, will the
> > server assign fewer addresses or send AddrUnavail?
> > 
> > BV> I would only return AddrUnavail if NO addresses are available. If you
> > can assign some, give the client those. It can make a decisions as to 
> > whether it wants to accept them or not.
> 
> VB> agreed.
> 
> > 
> > - 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?
> > 
> > BV> The Renew message does not need to include those options (including
> > them in an ORO is probably a good idea so the server knows you want them).
> > It is really the Reply that matters and the server will Reply with the
> > current settings. The client can then apply those values. The server will
> > (I suspect) not really check them - it just Replies with the current
> > values.
> 
> VB>  Sending  the ORO  option is best  idea.  I think we need to add the
> mechanism  of renewal of other  parameters  (sending  ORO option) in the
> draft.
> 
> BV2> Yeah, but that is already clear. See 22.6 (ORO option) text. And also
> Appendix B

VB2> Agreed

> > few addresses be relased from an IA? (partial release)
> > 
> > BV> Individual addresses can be released or declined. The client MUST 
> > include the addresses to decline/release. The server ignores any addresses
> > that the client doesn't "own".
> > 
> > - 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?
> > 
> > BV> It can send a NoBinding status for that IA. (And renew the others.)
> > 
> > - What will the client do, for the multiple IAs sent for renew, only one
> > IA is missing in the reply?
> > 
> > BV> No sure what you asking? Is this a follow up to the previous question?
> > If the IA returns with a NoBinding status, the client may either continue
> > to use those addresses (since it must have gotten them from someone in the
> > past) or drop them (and the IA).
> > 
> > - 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?
> > 
> > BV> Have to look into this one more.
> > 
> > - 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?
> > 
> > BV> Have to look into this one more.
> > 
> > - 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.
> > 
> > BV> Have to look into this one more.
> > 
> > - In the previous  versions, we have  Retransmission  Parameter  option.
> > Why it was removed?
> > 
> > BV> There are significant security / DOS issues with allowing the server
> > to set parameters. Also, there are issues as when these parameters are to
> > be used (vs the defaults). If a client moves to a completely different
> > DHCP domain, the parameters may not be valid and how does it know that?
> 
> VB> Agreed
> 
> > 
> > - Some useful options were defined in DHCPv6 extension draft.  When will
> > those options be included in this draft?
> > 
> > BV> Suggest the ones you want to have included! Provide the text (if it
> > needs to be revised). That's what Ralph (as editor) has requested in the
> > past.
> 
> VB> I think, there are some basic configuration  parameters for the host
> to work comfortably.  We can add options for getting those configuration
> parameters.  The options are,
> 
> NIS, NIS+, NTP server addresses, SLP DA addresses and its scope list.
> NIS and NIS+ client domain name, Time Zone.
> hostname,FQDN,static route option.
> 
> If you are  agreeing in adding these  options to base spec,i can provide
> the text.
> 
> BV2> Supply proposed text (similar to the existing Options sections). If you don't
> supply it, the options won't be in the base spec. If you do, it will just depend on
> what the WG thinks of them. I don't really see any significant reason not to include
> the ones you propose. I think the major issue is to have a clear reason for the option
> and to assure it is well define/specified. One tactic that has been used is to wait
> to define the options until a clear need is found (since then a clearer specification of
> the option can be written!).

VB2> I am sending it in a seperate mail.


-- 
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
______Ph:_2051424________
____Telnet:_847_1424_____
___Pager:_9624_371137____


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