Linksys + Juniper = Considered Harmful

[sthaug at nethelp.no]

> What does this 'extended DHCP relay' mean?  Well, I don't know, but I
> know how it behaves differently from their (better) BOOTP
> implementation on the wire.

It has considerably more functionality. But it's also newer, so I'm
not too surprised that there are bugs to be found.

> First, their extended DHCP relay does not support unicast-without-arp.
> So INIT state clients that haven't been configured yet, but have
> signaled they can receive unicasts by clearing the BROADCAST flag,
> will still receive broadcast responses (DHCPOFFER and DHCPACK).  This
> isn't a problem, except that their BOOTP agent code unicasts just
> fine.  Why would anyone take this step backwards?  It's just a waste
> of your broadcast channel.

I can partially reproduce this. Using a FreeBSD 7.0 box with an ISC
client, Discover and Request are sent with the BROADCAST cleared.  My
Juniper router, running JunOS 9.2R3.5 with the 'extended DHCP relay'
functionality, sends the Offer to IP 255.255.255.255/Ethernet broadcast,
but the ACK is sent unicast to the requested address.

> Second, their Extended DHCP Relay Agent sets the IP TTL field of
> packets they transmit to 1.  Their BOOTP relay agent actually lets you
> configure the IP TTL.  The default is not 1 (I don't actually know the
> default, we started out configuring 16 to control variables).

Same here. The Offer is sent from the Juniper router with TTL 1, the ACK
with a normal TTL.

> The moral of the story is to avoid Juniper's Extended DHCP Relay
> Agent.

I would rather say that the moral is to get this problem reported to
Juniper and fixed.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no