Re: [dhcwg] Comments on 22 rev of the draft
Ralph Droms <rdroms@cisco.com> Mon, 21 January 2002 20:04 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 PAA22248 for <dhcwg-archive@odin.ietf.org>; Mon, 21 Jan 2002 15:04:18 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25452 for dhcwg-archive@odin.ietf.org; Mon, 21 Jan 2002 15:04:21 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24908; Mon, 21 Jan 2002 14:57:37 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24887 for <dhcwg@optimus.ietf.org>; Mon, 21 Jan 2002 14:57:35 -0500 (EST)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22052 for <dhcwg@ietf.org>; Mon, 21 Jan 2002 14:57:31 -0500 (EST)
Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com [161.44.149.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05939; Mon, 21 Jan 2002 14:53:22 -0500 (EST)
Message-Id: <4.3.2.7.2.20020121144941.0324ff90@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 21 Jan 2002 14:53:49 -0500
To: Vijay Bhaskar A K <vijayak@india.hp.com>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] Comments on 22 rev of the draft
Cc: Bernie.Volz@am1.ericsson.se, vijayak@india.hp.com, Bernie.Volz@am1.ericsson.se, dhcwg@ietf.org
In-Reply-To: <200201181738.XAA16245@dce.india.hp.com>
References: <66F66129A77AD411B76200508B65AC69B4CDB4@EAMBUNT705>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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 11:08 PM 1/18/2002 +0530, Vijay Bhaskar A K wrote: >Bernie, > >See my comments prefixed by VB2> > >~ Vijay > > > Vijay, see BV2> comments. > > > > - Bernie > > > > -----Original Message----- > > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > > Sent: Thursday, January 17, 2002 4:35 AM > > To: Bernie.Volz@am1.ericsson.se > > Cc: vijayak@india.hp.com; dhcwg@ietf.org > > Subject: Re: [dhcwg] Comments on 22 rev of the draft > > > > > > See my comments inline prefixed by VB> > > > > ~Vijay > > > > > Let me try to answer these based on my understanding/view of -22. > > > > > > See below. > > > > > > - Bernie > > > > > > -----Original Message----- > > > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > > > Sent: Wednesday, January 16, 2002 1:05 PM > > > To: dhcwg@ietf.org > > > Cc: vijayak@dce.india.hp.com > > > Subject: [dhcwg] Comments on 22 rev of the draft > > > > > > > > > I had gone through the latest rev of DHCPv6 draft. Sorry for the delay > > > in telling the comments. > > > >[...] > > > - Till what time, these OFFERED addresses are preserved for those > > > clients to assign? > > > > > > BV> My opinion is that the ADVERTISED addresses are just a possible > set of > > > addresses the client will get and may not be the exact addresses. The > client > > > must wait until the Reply to the Request before it knows which > addresses it > > > got and before it does Duplicate Address Detection. The ADVERTISE should > > > include all of the parameters the client is likely to receive in the > Reply, > > > but they are just possible values and not the actual values. > > > > VB> What i am asking is, in V4, there is a concept called OFFERED > > addresses, which will be reserved to a client. The server reserves that > > addresses for the some predefined time. At the expiration of the time, > > if the client has not sent the request, it will be allocated to some > > other clients. I disagree that DHCPv4 requires that a server explicitly reserve an address it has offered to a client. From RFC2131: 3.1 Client-server interaction - allocating a network address [...] 2. Each server may respond with a DHCPOFFER message that includes an available network address in the 'yiaddr' field (and other configuration parameters in DHCP options). Servers need not ^^^^^^^^^^^^^^^^ reserve the offered network address, although the protocol will ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ work more efficiently if the server avoids allocating the offered network address to another client. When allocating a new address, servers SHOULD check that the offered network address is not already in use; e.g., the server may probe the offered address with an ICMP Echo Request. Servers SHOULD be implemented so that network administrators MAY choose to disable probes of newly allocated addresses. The server transmits the DHCPOFFER message to the client, using the BOOTP relay agent if necessary. > I think, if we follow the same policy, it will be > > better. Assume, a client sends a SOLICIT and the server replies with > > ADVERTISE with some addresses. Before the client sending the Request, > > if some other client requests for the addresses, with the current > > mechanism, the server will assign the addresses to new client. It may > > lead to server to send AddrUnavail to the first client, if the server > > has only limited number of addresses. It will lead to unnecessary > > packet transactions. > > > > BV2> I don't agree. It is much better if the server can just send something > > out and not have to do anything to remember it. With IPv6, what's the > likelyhood > > that an address won't be available - we have 2^64 addresses on each prefix! > > > > BV2> What I view the ADVERTISE message to be is for the server to say I am > > willing to give you this stuff [assuming it is avaiable] but that I haven't > > given you the EXACT stuff you will get (since that happens in the Reply to > > the Request). > > > > BV2> BUT please note that this really is up to each SERVER to do what it > > wants. A SERVER can chose to ADVERTISE real stuff and "reserve" it for some > > period of time (and that is a SERVER implementation issue). In my server, > > I might chose that time to be 0 seconds. In your server, you can set it to > > 1 hour. The client can't do anything with ADVERTISEd information other than > > make a decision based on which ADVERTISE it wants to accept (assuming > it gets > > multiple). In any case, the information from the Reply is what it must > install. > > So, this is purely a server implementation issue. > >VB2> Yes. I agree that this is purely an implementation issue. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- RE: [dhcwg] Comments on 22 rev of the draft Bernie Volz (EUD)
- RE: [dhcwg] Comments on 22 rev of the draft Ralph Droms
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- RE: [dhcwg] Comments on 22 rev of the draft Bernie Volz (EUD)
- RE: [dhcwg] Comments on 22 rev of the draft Bernie Volz (EUD)
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- RE: [dhcwg] Comments on 22 rev of the draft Bernie Volz (EUD)
- RE: [dhcwg] Comments on 22 rev of the draft Vijayabhaskar A K
- RE: [dhcwg] Comments on 22 rev of the draft Bernie Volz (EUD)
- Re: [dhcwg] Comments on 22 rev of the draft Ralph Droms
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- Re: [dhcwg] Comments on 22 rev of the draft Ted Lemon
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- Re: [dhcwg] Comments on 22 rev of the draft Ted Lemon
- Re: [dhcwg] Comments on 22 rev of the draft Ted Lemon
- Re: [dhcwg] Comments on 22 rev of the draft Martin Stiemerling
- Re: [dhcwg] Comments on 22 rev of the draft Jim Bound
- Re: [dhcwg] Comments on 22 rev of the draft Martin Stiemerling
- [dhcwg] Question on DHCPv6 Draft 23. Paul Tan