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

[Vijayabhaskar A K <[e-mail]>]

> 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 : [phone]
Hewlett Packard              Mobile: [phone]
29 Cunningham Road           Telnet: 847-3085
Bangalore 52                 Email : [e-mail]

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