Subject: DHCP-DISCOVER on new subnet

From: "Michael W. Patrick" <[email-masked]>
Date: Fri, 07 Apr 2000 15:14:24 -0400

DHCPv4-list,

Related to the subject of renewals on a new subnet is the problem
of DHCP-DISCOVER by a client that changes its subnet.

We currently have this problem in some deployed cable modem networks.
The problem when a cable modem (CM) can "hear" the downstream
transmissions of different head-end "cable modem termination systems"
(CMTSs) that act as routers (and DHCP relay agents). 
DHCP packets are relayed by both CMTSs to the same DHCP server.

After performing DHCP on one CMTS (and obtaining a lease on that
CMTS's subnet), the CM may be instructed to switch to a different
downstream channel, for the other CMTS. In effect, this is as if the
DHCP client decided itself to switch to a different subnet, and needs
to get a new IP address on that subnet.

The problem we've seen in the field is that some DHCP servers
will return the "old" IP address, even though the client
performs a DHCP-DISCOVER (and the new CMTS adds its proper giaddr). 
This behavior of the server is allowed and indeed encouraged
(with "SHOULD") by the RFC2131, section 4.3.1:

----
4.3.1 DHCPDISCOVER message

   When a server receives a DHCPDISCOVER message from a client, the
   server chooses a network address for the requesting client.  If no
   address is available, the server may choose to report the problem to
   the system administrator. If an address is available, the new address
   SHOULD be chosen as follows:

      o The client's current address as recorded in the client's current
        binding, ELSE

      o The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      o The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      o A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

----

If the DHCP server does NOT use the above algorithm, and recognizes
that the giaddr of the new DHCP-DISCOVER from the client represents
a "moved" client, then the "multiple CMTS" problem is avoided. 
Some DHCP servers indeed do this.

Here's my questions to the group:

1.  Which DHCP server vendors avoid the 'multiple CMTS' problem?
    That is, which DHCP servers will recognize a relayed DHCP-DISCOVER
    from a client that has moved to a new scope and will therefore
    give it a proper address on that subnet?

2.  Shouldn't the algorithm in 4.3.1 be modified to REQUIRE
    servers to recognize DHCP-DISCOVERs with a giaddr that is
    not in the scope of the current (or last)  client lease,
    and for which a new scope must therefore be identified?

3.  Am I missing something that Cable Modem clients can do to FORCE the DHCP
    server to abandon the old lease and give them a new lease on the
    new subnet?
    Even if the CM did a DHCP-RELEASE before the new DHCP-DISCOVER,
    bullet 2 of 4.3.1 suggests that the server return the old lease
    anyway!

At the moment, our workaround "non-recognizing" servers is to add
reservations for the same client on BOTH CMTS subnets. This doesn't
scale well, and we'd like to have automatically-assigned leases.  And
we can't do this unless the DHCP server properly recognizes a changed
client subnet. Shouldn't we require this of servers?

Thanx,
mike

---

From: Ted Lemon <[email-masked]>
Date: Fri, 07 Apr 2000 16:31:49 -0700

> to get a new IP address on that subnet.

Hm.  Is it the case that before the switch, the client will only be
heard through one CMTS relay agent, and after the switch, the client
will only be heard through the other?  If that's the case, then the
DHCP server should not be assigning IP addresses on one subnet to the
client when it is being relayed through a relay agent on another
subnet.

If the client is being heard through both relay agents all the time,
then you have a nasty problem to deal with.   Can you clarify which of
these situations holds true?   If the former situation is true, then
the DHCP server is probably misconfigured.   The DHCP server depends
heavily on the administrator to describe the network layout, and if
the administrator makes a mistake, the sort of error that you're
talking about could easily happen, and does not represent a server
bug.

			       _MelloN_

---

From: "Michael W. Patrick" <[email-masked]>
Date: Sat, 08 Apr 2000 08:01:41 -0400

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:

>> downstream channel, for the other CMTS. In effect, this is as if
>> the DHCP client decided itself to switch to a different subnet, and
>> needs to get a new IP address on that subnet.

> DHCP server should not be assigning IP addresses on one subnet to
> the client when it is being relayed through a relay agent on another
> subnet.

> then you have a nasty problem to deal with.  Can you clarify which
> of these situations holds true?  If the former situation is true,
> then the DHCP server is probably misconfigured.  The DHCP server
> depends heavily on the administrator to describe the network layout,
> and if the administrator makes a mistake, the sort of error that
> you're talking about could easily happen, and does not represent a
> server bug.

> 			       _MelloN_

Ted, thanx for responding.

The DHCP server will see the modem only through one CMTS at a time.
So the server sees an initial single DHCP-DISCOVER with CMTS1's giaddr,
and a few seconds later it will see a second DHCP-DISCOVER with 
only CMTS2's giaddr.  The first lease (via CMTS1) will not have expired.

I agree that the server *should* discard the first lease and generate
a second one with the different giaddr. It's just that RFC2131 
says the server "SHOULD" keep the first one!

-mike

---

From: Ted Lemon <[email-masked]>
Date: Sat, 08 Apr 2000 12:51:39 -0700

> says the server "SHOULD" keep the first one!

   2. Each server may respond with a DHCPOFFER message that includes an
      available network address in the 'yiaddr' field (and other
      configuration parameters in DHCP options).

I would say that a network address that is not on the subnet to which
the client is connected is not available, but you're right that this
isn't very explicit, and I can't find any other place in the RFC where
it is more explicit, and in particular, as you point out, in the
section on address allocation, it does not specifically say that the
old address should only be reused if the client is on the right
subnet.

However, I am pretty sure that what you are actually experiencing is a
misconfigured DHCP server, not a DHCP server that has been implemented
with a misunderstanding of the intent of this section of the draft.
While I think it's a good idea to clarify this section of the draft, I
would suggest that you investigate your customer's problem further, to
see if this is actually a protocol misunderstanding or a configuration
error.  I know it would be easy to misconfigure the ISC DHCP server to
behave in the way you describe, and I have had users do it in the
past.

			       _MelloN_