Subject: [dhcwg] Cisco 79xx VOIP Phone DHCPv4 client oddity

From: "David W. Hankins" <[email-masked]>
Date: Thu, 25 Feb 2010 16:00:53 -0800

I'm receiving reports that, running up-to-date firmware, the 7900
series of phones is exhibiting what I think is an odd condition in
the INIT-REBOOT (I assume) state;

1) It transmits from 0.0.0.0 to 255.255.255.255, not so surprising,
   a DHCPREQUEST message.

2) It sets 'ciaddr' to its previous IPv4 address!  I can't determine
   if it also sets the requested-address option (I don't know if the
   folks reporting this are tcpdump'ing truncated packets, it seems
   to me they are).

3) Any attempts to reach the phone by the 'ciaddr' address do not
   work; the phone is clearly un-configured in this state (so I think
   it is in INIT-REBOOT, but RFC 2131 clearly says the client MUST
   set ciaddr to zero...).  It doesn't answer ARP's for that address.

We have an interoperability problem when this client is not behind a
relay agent - when giaddr is not set, RFC 2131 next directs a server
to unicast to ciaddr if it is set.

This unicast causes the DHCP server to ARP for the address as it is
directly connected, and the phone never answers the ARP.

Apparently, the phones also never time out of this state to go to
INIT...but I don't know if the reports of "never" I'm hearing are in
fact an "infinite" number or merely "longer than an operator will
wait before receiving a complaint," so...

I'm poring over RFC 2131 and I'm not seeing a condition where it is
normal to be unconfigured (so, using broadcast) and to set 'ciaddr'...
if anyone has any different information, please share...but this is
a pretty damning summation;

   ciaddr        4  Client IP address; only filled in if client is in
                    BOUND, RENEW or REBINDING state and can respond
                    to ARP requests.

There are evidently a lot of other DHCP servers, including the one
in Cisco IOS, that on native connections with this client will
respond directly without an ARP.  I think that's completely
reasonable behaviour from a certain point of view, because the client
does supply its chaddr after all...basically an optimization to use
that rather than to interrogate ARP.

Because of that pre-extant other-server behaviour, and how many of
these phones are out there, we're going to adopt a change to work with
this client along those lines (I'm not sure what strategy just yet),
but I also wanted to ask if there are any folks who know the folks who
do the firmware on the 7900's?

There may be other DHCP servers out there that rely on being able to
ARP to clients that set ciaddr...may be good to get this changed for
maintenance...

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/