Subject: [dhcwg] Re: DHCP behind NAT

From: Bernard Dugas <[email-masked]>
Date: Wed, 29 Aug 2001 11:32:17 +0200

Hello,

I've had no comment on that. Is it the right procedure ?

The patch is loadable at http://www.is-pronet.com/download/, with the
original version and the patched version of ISC dhcpd we were using.

Best regards, and thanks for help of mailing lists and open source
process ! 

Bernard Dugas a écrit :
> 
> Hi,
> 
> I have a comment to do on both RFC :
> - Dynamic Host Configuration Protocol (RFC 2131);
> - DHCP Relay Agent Information Option (RFC 3046).
> 
> I couldn't find in these RFC's any mention of the possibility of a DHCP
> client being on a subnet behind some NAT device like a router.
> 
> NAT is used quite often, specially in the kind of network represented in
> RFC3046 Figure 1 page 3, with network clients behind modems.
> 
> Even more, it seems that the behaviour described by RFC2131
> is preventing a dhcp server to answer to a client behind a NAT.
> 
> 3 problems have been identified :
> - PB1) In the case of a unicast DISCOVER, with a relay involved, the
> DHCP
> server is answering to the ip address of the relay (giaddr field). In a
> non-NAT context, the giaddr is the same that the source ip address of
> the DISCOVER packet. But with NAT, the DHCP server MUST answer to the IP
> source address of the DISCOVER packet. This problem may happen also in
> other requests.
> 
> cf. "  If the 'giaddr' field in a DHCP message from a client is
> non-zero,
>    the server sends any return messages to the 'DHCP server' port on the
>    BOOTP relay agent whose address appears in 'giaddr'. "
> in :
> " Droms                       Standards Track                    [Page
> 23]
> RFC 2131          Dynamic Host Configuration Protocol         March 1997
> "
> 
> - PB2) The same apply for to UDP port of the OFFER packet : it should be
> the udp port of the IP source address of the DISCOVER packet, because
> NAT may have changed the port too ;
> 
> - PB3) The DHCP server is issuing a ICMP echo on client address before
> answering with the OFFER. In a NAT context, the echo can't go on the
> client subnet. The RELAY should do the ping before relaying the OFFER.
> 
> To illustrate the PB1, I can send you a patch on ISC dhcp 3.0.RC11,
> which allow our DHCP server to answer to clients behind NAT.
> 
> I would be very grateful to have an answer on these problems. Thanks a
> lot.

-- 

 __________ Bernard DUGAS ________________________________________
|                                                                 |
|  Technoparc Pays de Gex  mailto:[email-masked] |
|  30 Rue Auguste Piccard           Tel.: +33 450 205 105         |
| FR 01630 St Genis Pouilly         Fax : +33 450 205 106         |
|_________________________________________________________________|

_______________________________________________
dhcwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Aug 2001 12:54:47 -0400

There's no way to make your proposed change RFC2131 at this late date.
Too many devices have been deployed that follow the current protocol
specification.   In order to do what you need, you have to come up
with a different method.   I would recommend that you investigate the
subnet selection option.   Send the address to which you want the
reply sent in giaddr, and use the subnet-selection-option to store the
address you would otherwise have stored in giaddr.

I agree with you, by the way, that your proposed way of doing this is
better than the way that RFC2131 does it.   The problem is not that
you're wrong, but that you're too late - this behavior was
canonicalized in RFC951, and that's the last time it was possible to
fix this the way you propose.   :'}

			       _MelloN_