Subject: RE: [dhcwg] Comments on 22 rev of the draft

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 16 Jan 2002 13:08:33 -0600

Let me try to answer these based on my understanding/view of -22.

See below.

- Bernie

-----Original Message-----
From: Vijay Bhaskar A K [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 1:05 PM
To: [email-masked]
Cc: [email-masked]
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.

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

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

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

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

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

- Should release/decline of addresses be done for IA as whole?  (or) Can
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?

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

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Wed, 16 Jan 2002 22:53:16 -0500

My thoughts on these issues...

- Ralph

At 01:08 PM 1/16/2002 -0600, Bernie Volz (EUD) wrote:

>From: Vijay Bhaskar A K 
>[<mailto:[email-masked]>mailto:[email-masked]]
>BV> I think this would be good to say that a client MUST place the DUID 
>option in a mesage before any IA options.

RD - I'm willing to put in the text, but I don't see how it makes the 
processing easier.

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

RD - I'm willing to make this change.

>v- Section 13 says the ways for selecting  addresses  for  assignment  in
>available  at  <http://software.hp.com/>http://software.hp.com/  You 
>can  download it and tell me
>your comments.
>

RD - To expand on Bernie's response, the server is free to assign
an address according to whatever rules it might be configure with,
once the server has determined the link to which the client is
attached.

>BV> I don't understand what you are asking here.

RD - It's possible to encode a rule for address assignment
based on DUID, which would be what is sometimes called a
"reservation" in some DHCPv4 servers.

>server. Later, when a third application starts, the client will need

RD - The complexity comes not so much from adding an address
to an IA as from the semantics of how to request that the
server add a new address to an IA.  So, a server can replace
temporary addresses in an IA as lifetimes on existing addresses
expire; if a client wants more addresses, it sends a new IA.

>BV> YES the can both be in the SAME IA. That is the intention.

RD - Agreed.

>updates for the client, is must adhere to the requirements of RFC 3041

RD - Registering a temporary address in DNS defeats the anonymity
provided by that address.  Clients won't want to register temporary
addresses; a server may register according to the rules
in RFC3041.

>AAAA processing and using the DUID for the client identification).

RD - Agreed.

>BV> Yes, we will need this.

RD - Agreed.

>LOTS of addresses (one set per IA).

RD - Agreed.

>Advertise messages are received.

RD - Agreed.

>BV> Haven't studied this issue.

RD - I don't understand the way you've explained the issue.  If
the client has received an Advertise message, it will terminate
the retransmission process and accept the Advertise message.

>use one of the LINK interface addresses.

RD - OK...

>BV> It depends on the server's policies.

RD - Agreed.

>but they are just possible values and not the actual values.

RD - Agreed; the intention is that the Advertise message is
advisory and not a firm promise of addresses to be assigned to
the client.

>whether it wants to accept them or not.

RD - Agreed.

>(I suspect) not really check them - it just Replies with the current

RD - Agreed.

>that the client doesn't "own".

RD - Agreed.

>BV> It can send a NoBinding status for that IA. (And renew the others.)

RD - Agreed.

>past) or drop them (and the IA).

RD - I agree; the client can continue to use the addresses in the
un-Renew-ed IA until the lifetimes for those addresses expire.

>DHCP domain, the parameters may not be valid and how does it know that?

RD - Agreed; in fact, when a client moves to a new link (which is
the case in which the Retransmission Parameter option would be used
to change the client's behavior for the new link), it's too late
because the client has potentially already used the retransmission
mechanism on the new link, using the parameters from the old link.

>needs to be revised). That's what Ralph (as editor) has requested in the

RD - Please do send requests for other options.

>some sentences in between.

RD - I'll fix these in the -23 rev of the draft.

>____<Telnet:_847_1424_____>Telnet:_847_1424_____
><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg 
>

---

From: Vijay Bhaskar A K <[email-masked]>
Date: Thu, 17 Jan 2002 15:05:22 +0530 (IST)

See my comments inline prefixed by VB>

~Vijay 

> 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) befor…

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.

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

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

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

> whether it wants to accept them or not.

VB> agreed.

> (I suspect) not really check them - it just Replies with the current

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.

> DHCP domain, the parameters may not be valid and how does it know that?

VB> Agreed

> needs to be revised). That's what Ralph (as editor) has requested in the

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.

---

From: Vijay Bhaskar A K <[email-masked]>
Date: Thu, 17 Jan 2002 16:14:33 +0530 (IST)

See my reply inline.

~Vijay

> RD - I'm willing to put in the text, but I don't see how it makes the 

VB> If DUID  occurs  before  the IA  option,  then, it will be easier to
locate the bindings of the client and then process the IA by IA.

> expire; if a client wants more addresses, it sends a new IA.

VB> We can  use  similar  option  like  OPT_RTA.  If all the  additional
addresses  obtained  are  added to same  IA, then we can do renew in one
short.  Thus, preventing, multiple renew messages going to server.

> >AAAA processing and using the DUID for the client identification).

VB> Firstly, in most of the places, i am not able to identify whether you are agreeing my comments or bernie's.

> the retransmission process and accept the Advertise message.

VB> We need to be more  specific.  The  algorithm in Section 15 says, if
MRC and MRD are 0, the  transaction  is  infinite  until  the  reply  is
obtained.  The  variation  of this  algorithm  in 17.1.2  says that, the
client should be waiting in collecting the advertise messages even if it
has received advertise  message.  And, it does not say at what time, the
client should stop collecting the advertise  message.  So, this text has
to be added.

> advisory and not a firm promise of addresses to be assigned to

VB> Please refer my reply to bernie's mail...

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