Re: [dhcwg] Re: DHCP behind NAT

Bernard Dugas <> Sat, 01 September 2001 12:07 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id IAA12776; Sat, 1 Sep 2001 08:07:11 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id IAA23161; Sat, 1 Sep 2001 08:06:07 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id IAA23139 for <>; Sat, 1 Sep 2001 08:06:05 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id IAA12718 for <>; Sat, 1 Sep 2001 08:04:42 -0400 (EDT)
Received: from (unknown []) by (Postfix) with ESMTP id 311B7387FC; Sat, 1 Sep 2001 14:06:02 +0200 (MEST)
Message-ID: <>
Date: Sat, 01 Sep 2001 13:57:07 +0200
From: Bernard Dugas <>
Organization: Originale
X-Mailer: Mozilla 4.75 [fr] (WinNT; U)
X-Accept-Language: fr,en
MIME-Version: 1.0
To: Ted Lemon <>
Subject: Re: [dhcwg] Re: DHCP behind NAT
References: <>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>
Content-Transfer-Encoding: 8bit


Ted Lemon a écrit :
> 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.   :'}

It's the 1st time that somebody tells me I've been born too late,
normally this is the opposite ;-)

Note that answering the ip source address is exactly the same that
answering the giaddr in a normal routed network, as the relay is the ip
source. So the proposed patch is not changing any behaviour in a normal
routed network, it's just changing behaviour in NAT context.

> 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.

So I have to tell that to Cisco, so they change the way their NAT handle
DHCP relayed packet : only their NAT knows what is the right address to
answer to.

> 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. 

So ISC DHCPD will be the only available with a patch for NAT context,
and I will be the only ISP with a NAT service for its customers ;-)

More seriously, what is the point of a Request For Comment if valid
comments can't be  included ? Actually, I had no time to learn the
normal process of IETF, so I may have missed some points in the process.
I should spend some time on that.

Did you see the patch at :

By the way, the ip source address is now in the lease struct, but not
the udp source port : a complete patch should certainly add it.

Thanks a lot for your answer, and for your work with this powerful ISC
DHCP server.

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

dhcwg mailing list