Re: [dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed Standard
John Schnizlein <jschnizl@cisco.com> Sat, 29 September 2001 01:39 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 VAA29523; Fri, 28 Sep 2001 21:39:02 -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 VAA29578; Fri, 28 Sep 2001 21:37:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29554 for <dhcwg@optimus.ietf.org>; Fri, 28 Sep 2001 21:37:39 -0400 (EDT)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29513 for <dhcwg@ietf.org>; Fri, 28 Sep 2001 21:37:32 -0400 (EDT)
Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn1-95.cisco.com [10.82.224.95]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA13698; Fri, 28 Sep 2001 18:36:58 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010928151854.0328e018@diablo.cisco.com>
X-Sender: jschnizl@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 28 Sep 2001 15:52:57 -0400
To: Thomas Narten <narten@raleigh.ibm.com>
From: John Schnizlein <jschnizl@cisco.com>
Subject: Re: [dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed Standard
Cc: Keith Moore <moore@cs.utk.edu>, dhcwg@ietf.org
In-Reply-To: <200109281834.OAA25641@rotala.raleigh.ibm.com>
References: <Message of "Thu, 27 Sep 2001 15:32:42 EDT." <200109271932.PAA20346@astro.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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
At 02:34 PM 9/28/2001, Thomas Narten wrote: >.. >There is a general issue of when should (and shouldn't) a DHCP-learned >option override a manually configured one. My guess is that >DHCP-learned options generally do not override manually configured >ones. But I suspect that this is all considered implementation >specific. Can other DHC WG members comment? Since there is at least one widespread case in which DHCP-learned options MUST override manually configured ones, it would be wrong to prohibit it. The case is acquiring (through DCHP) the addresses of DNS servers when connecting to a VPN. The DNS servers able to resolve private names are often not available to the general Internet, but necessary once the host's traffic tunnels behind the firewall. Using DHCP both before and after establishing the tunnel does not work with cable-access that requires an enterprise-incompatible host-name to validate DHCP requests. >What do existing RFCs say about this point? > >Would it suffice to add some language stating that >*** in the case of this option, *** [emphasis added] >it should not override a manually configured search list? Separate from the case above (and possibly the general case), the order in which domain suffixes are applied is not critical to operation, but could lead to wasteful time-outs. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Re: Last Call: DHCP Domain Search Option … Thomas Narten
- Re: [dhcwg] Re: Last Call: DHCP Domain Search Opt… John Schnizlein
- [dhcwg] Re: Last Call: DHCP Domain Search Option … Keith Moore
- [dhcwg] Re: Last Call: DHCP Domain Search Option … Thomas Narten
- RE: [dhcwg] Re: Last Call: DHCP Domain Search Opt… Bernie Volz (EUD)