DHCP relay with UDP source port of 67 causes ISC 3.0.2 to respond with UDP source port of 1

[Frank Bulk]

I've been battling a problem for a while and I'm looking for some help.

We upgraded our CMTS to a new major release that changed it's DHCP relay
behavior from relaying UDP src/dst ports of 68/67 to match draft RFC
recommendations of 67/67.  

http://www.ietf.org/internet-drafts/draft-ietf-dhc-implementation-02.txt
=====================  
     4.7.2 Relay Agent Port Usage 
        Relay agents should use port 67 as the source port number. Relay 
        agents always listen on port 67, but port 68 has sometimes been used

        as the source port number probably because it was copied from the 
        source port of the incoming packet. 

        Cable modem vendors would like to install filters blocking outgoing 
        packets with source port 67. 

        RECOMMENDATIONS: 
        O  Relay agents MUST use 67 as their source port number. 
        O  Relay agents MUST NOT forward packets with non-zero giaddr 
           unless the source port number on the packet is 67. 
=====================

When we do that, DHCP Discovers to ISC dhcpd (running on a 3rd-party
appliance) returns to the CMTS with a DHCP Offer of 1/67 rather than the
67/67.  Many Windows client don't seem to like this offer because of the
source port of 1 and just drop the packet, issuing another DHCP Discover.

We had to downgrade the CMTS to get our subscribers back to a good state,
but I've been able to simulate the problem by using bittcap to inject
earlier-captured DHCP Discover packets into the network.  When I change the
source port to 68/67 using bittcape, those DHCP Discovers result in proper
DHCP Offers of 67/67.

Has anyone else seen this, does newer ISC dhcpd code resolve this, and if
not, where in the code is this being done so that this can be fixed?

Regards,

Frank