DHCPv6 Information Request, Information Refresh Time Option clarification request

Carsten Strotmann (Men & Mice) carsten.strotmann at menandmice.com
Wed Mar 2 12:47:17 UTC 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello ISC DHCP users,

I have worked with the ISC DHCP server and client today (Version 4.2.1,
on MacOS X) getting DHCPv6 information request with "Information Refresh
Time Option, RFC 4242" to work.

RFC 4242 states:

> 3.2.  Client Behaviour
> 
>    A client MUST request this option in the Option Request Option (ORO)
>    when sending Information-Request messages to the DHCPv6 server.  A
>    client MUST NOT request this option in the ORO in any other messages.
> 
>    If the Reply to an Information-Request message does not contain this
>    option, the client MUST behave as if the option with value
>    IRT_DEFAULT was provided.
> [...]

The behavior that I see in the default configuration if the ISC DHCP
client, when sending a DHCPv6 information request (dhclient -S), is:

* the "Information Refresh Time Option" is not requested by the client
(and not send by the server)
* the client retrieves the information request data and terminates. It
does not used IRT_DEFAULT and stays in the background.

tcpdump data from the default behavior:

13:29:58.870786 IP6 (hlim 1, next-header UDP (17) payload length: 44)
fe80::226:b0ff:fed6:a4e0.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp
sum ok] dhcp6 inf-req (xid=7b23c6 (client ID hwaddr/time type 1 time
352377172 0026b0d6a4e0) (option request DNS DNS name) (elapsed time 0))

13:29:58.876608 IP6 (hlim 64, next-header UDP (17) payload length: 96)
fe80::20b:2fff:fee1:ac2f.dhcpv6-server >
fe80::226:b0ff:fed6:a4e0.dhcpv6-client: [udp sum ok] dhcp6 reply
(xid=7b23c6 (client ID hwaddr/time type 1 time 352377172 0026b0d6a4e0)
(server ID hwaddr/time type 1 time 336410124 000b2fe1ac2f) (preference
0) (DNS fd34:2e7e:5a30::1) (DNS name))


with the "Information Refresh Time Option" explicitly requested in
/etc/dhclient.conf:
- -----(snip)-----
also request dhcp6.info-refresh-time;
- -----(snip)-----

* the client requests the option, and uses the retrieved value to stay
in the background and re-issues the Information Request correctly

tcpdump of that behavior:

13:30:39.726413 IP6 (hlim 1, next-header UDP (17) payload length: 42)
fe80::226:b0ff:fed6:a4e0.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp
sum ok] dhcp6 inf-req (xid=7b23c6 (client ID hwaddr/time type 1 time
352377172 0026b0d6a4e0) (option request lifetime) (elapsed time 0))

13:30:39.728429 IP6 (hlim 64, next-header UDP (17) payload length: 61)
fe80::20b:2fff:fee1:ac2f.dhcpv6-server >
fe80::226:b0ff:fed6:a4e0.dhcpv6-client: [udp sum ok] dhcp6 reply
(xid=7b23c6 (client ID hwaddr/time type 1 time 352377172 0026b0d6a4e0)
(server ID hwaddr/time type 1 time 336410124 000b2fe1ac2f) (preference
0) (lifetime 90))

Do I miss some important information here, or is the default behavior of
the ISC dhcp client not in line with RFC4242 section 3.2? Is there a
reason for the current default behavior?

Best regards

Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1uPFUACgkQElgUYvSqn/S4+gCgseduJKbqO8NyNaTZ4d5mXUsw
QcYAnAkClXTsC9CTB0bNzgWZQOqicIzh
=r4m2
-----END PGP SIGNATURE-----



More information about the dhcp-users mailing list