Subject: [dhcwg] Comments on draft-venaas-dhc-lifetime-00.txt

From: Vijayabhaskar A K <[email-masked]>
Date: Wed, 19 Nov 2003 21:53:24 +0530

> Abstract
>
>   This document describes an option for specifying lifetime of other
>   configuration options. It's mainly intended for the stateless DHCP,
>   but also useful when there are no addresses or other entities with
>   lifetimes that can tell the client when to contact the DHCP server
>   and update its configuration.
>  
>
s/DHCP/DHCPv6/g

> 1. Introduction
>
>   For IPv6 many hosts will use stateless autoconfiguration as specified
>   in [RFC 2462] for address assignment, and use DHCP for other
>   configuration data. This other configuration data will typically have
>   no associated lifetime, hence there may be no information telling a
>   host when to update its DHCP configuration data.
>  
>
you may want to refer draft-chown-dhc-stateless-dhcpv6-renumbering-00 here

>   The option specified here tells the host the lifetime of the
>   configuration data. When the lifetime expires, the host should make a
>   new DHCP request, updating the current configuration. This request
>   would usually be an Information request. If the host fails to update
>   the information, it should keep the current configuration, and retry
>   at regular intervals.
>
>
> 2. Terminology
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in BCP 14, RFC 2119 [RFC
>   2119].
>
>
> 3. Lifetime option definition
>
>   A client supporting this option SHOULD include it in the Option
>   Request option when sending an Information-request message to the
>   DHCP server.
>  
>
I guess, it is applicable for  Request also... Moreover, why do you want 
to make the client to send this option always in the ORO option.. The 
better way could be, Whenever the server provides non-address 
configuration, it MUST include Lifetime option in the reply" Opinions?

Moreover, you should explain what the client is expected to do with this 
option... Since, you are introducing the lifetime for non-address 
params, you have to explain what the client should do if the lifetime 
expires...

I am thinking about a model, where there will be 2 lifetimes, preferred 
and valid..  Once the preferred life time expires, it should start 
unicasting the Information-request to renew the configure 
information.... By this way, it is possible to refresh the parameters 
even before it expire..  Once the valid life time expires, it should 
send a multicast Information-Request to All Relays mutlicast address... 
But, It should ignore the old configuration *only* after obtaining the 
configuration info from some other server....

You need to add text about the retransmission mechanism also... Look at 
RFC 3315.. It has some timer values associated with Information-Request

INF_MAX_DELAY     1 sec   Max delay of first Information-request
  INF_TIMEOUT       1 sec   Initial Information-request timeout
  INF_MAX_RT      120 secs  Max Information-request timeout value

Add text on client behavior and server behavior to explain it clearly....

You need to add some thing like, "If the client has address 
configuration obtained from the server, the client MAY ignore this 
option and send renew along with the IAs"

>   The format of the Lifetime option is:
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |       OPTION_LIFETIME         |           option-len          |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                           lifetime                            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      option-code: OPTION_LIFETIME (to be decided)
>
>      option-len:  4
>  
>
You need to change this option if you decide to use two timers...

>      lifetime:    lifetime in seconds
>  
>
can you explain it bit more here...

you may need to explain what are all the possible values it can have? Is 
0 valid? Do you want to provide the permanent lease with 0xffffffff? Or 
do you want to make 0xffffffff reserved ? I guess, the server should be 
able to make the lifetime as 0, to make the client stop using the 
configuration and initiate the fresh Information-request/Reply to obtain 
new configuration information.. 0xffffffff can be assumed as infinite 
lease and can be used in the network where the  configuration is stable 
and there wont be any change in it....

>
> 4. IANA Considerations
>
>   IANA is requested to assign an option-code for the lifetime option
>   from the option-code space defined in [RFC 3315].
>  
>
The format should be something like....

IANA is requested to assign an option code to the following options
  from the option-code space defined in "DHCPv6 Options" section of the
  DHCPv6 specification [1].

     Option Name            Value    Described in
  OPTION_NIS_SERVERS         tbd       Section 4
  OPTION_NISP_SERVERS        tbd       Section 5
  OPTION_NIS_DOMAIN_NAME     tbd       Section 6
  OPTION_NISP_DOMAIN_NAME    tbd       Section 7

The key is, you need to mention the Section #

>
> 5. Acknowledgments
>
>   Funding for the RFC Editor function is currently provided by the
>   Internet Society.
>
>
> 6. Security Considerations
>
>   This option is believed not have any effects on security.
>  
>
No.. There are security constraints...Any intruder can frame a reply 
packet with a very less life time in the lifetime option and make the 
clients to intiate requests in very short intervals, making the network 
flooded and servers overloaded.... DHCP authentication as defined in RFC 
3315 should be used for authentication...

You need to add a section where you should list the only messages in 
which this option can appear... Something like...

8. Appearance of these options
                                                                           
  The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name
  options MUST NOT appear in other than the following messages: Solicit,
  Advertise, Request, Renew, Rebind, Information-Request and Reply.
                                                                           
  The option number for these options MAY appear in the Option Request
  Option [1] in the following messages: Solicit, Request, Renew,
  Rebind, Information-Request and Reconfigure.

-- 
__________________________________________________________
Vijayabhaskar A K            Phone : +91-80-2053085
Hewlett Packard              Mobile: +91-9845241382
29 Cunningham Road           Telnet: 847-3085
Bangalore 52                 Email : [email-masked]

Until you have the courage to lose sight of the shore,
you will not know the terror of being forever lost at sea.
 __________________________________________________________

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

---

From: Stig Venaas <[email-masked]>
Date: Wed, 19 Nov 2003 18:23:47 +0100

> configuration, it MUST include Lifetime option in the reply" Opinions?

I'm pretty open on this point, not sure which is best.

> configuration info from some other server....

I'm not sure this is necessary, would like to get more opinions on this.

>  INF_MAX_RT      120 secs  Max Information-request timeout value

Will do.

> option and send renew along with the IAs"

Right. I can say that it's only used for options not having a specified
lifetime of their own, and if client sends a request, renew, rebind or
information-request message to the DHCP server before the lifetime has
expired, it MAY update all this data as well.

Actually, I think SHOULD might be appropriate. Are those the correct
message types?

> configuration and initiate the fresh Information-request/Reply to obtain 

But can't the server immediately offer the options, instead of setting
it to 0 and have a new request?

> and there wont be any change in it....

Maybe, but omitting the option or not supporting it should be the same,
right?

>  DHCPv6 specification [1].

ok, will change this.

> 3315 should be used for authentication...

My thinking is that the current lifetime value is forgotten when it
expires. Then when you get new config info, you'll either have a
correct value, or no value meaning infinite or unspecified (as it is
when option isn't supported). Obviously something that needs to be
spelled out in next version.

>  Rebind, Information-Request and Reconfigure.

Will do, thanks,

Stig

---

From: Vijayabhaskar A K <[email-masked]>
Date: Wed, 19 Nov 2003 23:46:56 +0530

>I'm pretty open on this point, not sure which is best.
Including this option in the ORO somehow makes this option unrelated to 
non-address configuration.. But it is not so.... They are tied together 
and server should be able to send this option if any of the non-address 
conf are requested.. The key thing is, life time is part of the 
non-address conf

>expired, it MAY update all this data as well.
Sounds good..

>Actually, I think SHOULD might be appropriate. Are those the correct
yes, the intention here is, instead of mainitaining two seperate life 
times for address and non-address conf, the clients can include the 
renewal of these info whenever it gets a chance to contact the server.. 
you can even say. this life time can be ignored, till it have a 
configuration which has associated life time in it..

>it to 0 and have a new request?
It may choose to stop serving this link and may want trigger the client 
to use some other dhcp server

>Maybe, but omitting the option or not supporting it should be the same,
yes.. but, in dhcp terms 0xffffffff has a meaning of infinite lease.. Do 
you want to keep it?

>spelled out in next version.
certainly, you have somethings to be added in this section

---

From: Tim Chown <[email-masked]>
Date: Wed, 19 Nov 2003 23:50:16 +0000

> to use some other dhcp server

Hmm, that's an interesting special case, where the DHCPv6 server is itself
being renumbered or changed.   Might be worth an explicit mention in the
text?
 
Tim

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 19 Nov 2003 19:46:36 -0500

FYI:

RFC 3315 states in Section 15, Message Validation:

   A server MUST discard any Solicit, Confirm, Rebind or
   Information-request messages it receives with a unicast destination
   address.

So, Information-Request *MUST* be multicast. It may not be unicast. (Also,
even if this rule were relaxed, the client MUST NOT unicast unless it
receives a Server Unicast option).

I don't see a need for a preferred and valid lifetime for configuration
information. Just a lifetime is sufficient. We should NOT call this a "valid
lifetime" as that has a well understood meaning in IPv6.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim
Chown
Sent: Wednesday, November 19, 2003 6:50 PM
To: DHCPWG
Subject: Re: [dhcwg] Comments on draft-venaas-dhc-lifetime-00.txt

 
Tim