Re: [dhcwg] Re: DHCP behind NAT

Ted Lemon <mellon@nominum.com> Sat, 01 September 2001 13:32 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14275; Sat, 1 Sep 2001 09:32:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24340; Sat, 1 Sep 2001 09:31:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24314 for <dhcwg@ns.ietf.org>; Sat, 1 Sep 2001 09:31:50 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14256 for <dhcwg@ietf.org>; Sat, 1 Sep 2001 09:30:25 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (dsl081-147-128.chi1.dsl.speakeasy.net [64.81.147.128]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f81DPof19496; Sat, 1 Sep 2001 06:25:50 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f81DVF300365; Sat, 1 Sep 2001 09:31:15 -0400 (EDT)
Message-Id: <200109011331.f81DVF300365@grosse.bisbee.fugue.com>
To: Bernard Dugas <bernard.dugas@is-production.com>
cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Re: DHCP behind NAT
In-Reply-To: Message from Bernard Dugas <bernard.dugas@is-production.com> of "Sat, 01 Sep 2001 13:57:07 +0200." <3B90CD13.8185CF4@is-production.com>
Date: Sat, 01 Sep 2001 09:31:15 -0400
From: Ted Lemon <mellon@nominum.com>
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

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

There's no reason to have this expectation.   A router normally has
several IP addresses, and any of them could be the source address.   I
would think it most likely that the source address would be the
IP address of the interface on which the relayed packet was sent to
the server, not the IP address of the interface on which the packet
was received.   This is of course usually a perfectly legitimate
address to which to return the packet.

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

I believe that Cisco supports the subnet selection option.

> 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 ;-)

Somehow I don't think that this will be exciting news for your
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.

Of course you can make comments, but the time to do so is when the
draft comes out, which in this case would have been sixteen years
ago.   I wish you *had* made this comment then.   :'}

> Did you see the patch at :
> http://www.is-pronet.com/download/dhcp-3.0rc11_NAT_patch.tar.gz

No, I'm not interested.   I think the subnet selection option solves
your problem, and it has the advantage of being standardized and not
requiring a patch to the server, although possibly the disadvantage of
not working with your router.   :'}

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

You're welcome!

			       _MelloN_

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg