2

Is there an address renew after the lease-time or after the half of the lease-time in DHCPv6 ? I´m not sure about, and I didn´t find that answer inside the RFC of DHCPv6.

4

DHCPv6 makes use of T1 and T2 timers. T1 timer is usually 50% of the preferred lifetime value. T2 is 80% of the preferred lifetime. When T1 timer expires, the DHCPv6 client sends a RENEW message. On receiving no response from the server, it waits until T2 expires and then sends a REBIND message.

  • So there is no lease-time anymore? And T1 and T2 have the functionality of the old lease-time ? – eragon-2006 Jun 27 '14 at 13:49
  • Yes, there is no lease time as such. T1, T2, valid and preferred lifetime have sort of replaced lease time. – BHV Jun 27 '14 at 13:57
2

Lease time indicates the amount of time the IP will be leased to that particular client. Most of the time, DHCP client makes a renew attempt when the half duration of lease time passes, and will cut the waiting time to half after each unsuccessful attempt(goes like: waits 50% of lease time, then waits 25% of lease time). If it cannot make a renew, it will attempt a rebind after the 87.5% of the lease time passes. I haven't seen any different DHCPv6 behavior yet, then again; I haven't seen much DHCPv6 traffic yet.

2

First of all, in IPv6 there is no longer one single 'lease time', but now two values determine an address/prefix lifetime. This is used in both SLAAC and DHCPv6.

  1. The preferred lifetime, during which you can use an address as you like.
  2. The valid lifetime, during which you should no longer use the address for new connections (e.g. when creating a socket), but can keep using it for existing connections. This provides some kind of graceful address deprecation.

The preferred lifetime gets closest to the IPv4 lease time from client perspective as this determines how long you can really use an IPv6 address as you want. But the valid lifetime comes closest to the IPv4 lease time from server perspective as only then the address may be returned to the pool and reassigned to another client.

On to DHCPv6, this protocol can actually manage multiple addresses, which are bundled in so called Identity Associations (IA). Currently there are 3 types of IA's: the IA_PD for assigning complete prefixes, IA_NA for assigning non-temporary /128 addresses and IA_TA for assigning temporary /128 addresses. It is on the IA level that the T1 (renew) and T2 (rebind) timers are specified as follows:

  • IA_PD: T1 and T2 are by default respectively .5 and .8 times the shortest prefered lifetime signaled in this IA. Other values can be sent to the client.
  • IA_NA: T1 and T2 are by default respectively .5 and .8 times the shortest prefered lifetime signaled in this IA. Other values can be sent to the client.
  • IA_TA: No T1 and T2 are used, as temporary addresses should be short-lived. The client can initiate a renew itself if it would need an address longer than the valid-lifetime, for example for some long-living connection like chat.

As T1 and T2 are specified on IA level, the renew and rebind should happen for all addresses in that IA at once. So if you have an IA_NA with 9 addresses with a preferred-lifetime of 1 day and one address with a preferred-lifetime of 5 minutes, you'll still renew every 2.5 minutes for all 10 addresses.

Another consequence is that you might be retrying rebinds for quite some time, as you actually should retry from T2 until the last valid lifetime in the IA is expired.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.