Re: [dhcwg] Comments on 22 rev of the draft
Vijay Bhaskar A K <vijayak@india.hp.com> Thu, 17 January 2002 10:53 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 FAA11536 for <dhcwg-archive@odin.ietf.org>; Thu, 17 Jan 2002 05:53:46 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25463 for dhcwg-archive@odin.ietf.org; Thu, 17 Jan 2002 05:53:49 -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 FAA25316; Thu, 17 Jan 2002 05:40:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25293 for <dhcwg@optimus.ietf.org>; Thu, 17 Jan 2002 05:40:56 -0500 (EST)
Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11359 for <dhcwg@ietf.org>; Thu, 17 Jan 2002 05:40:52 -0500 (EST)
Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel13.hp.com (Postfix) with ESMTP id C1265E006B9; Thu, 17 Jan 2002 02:40:17 -0800 (PST)
Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id QAA11498; Thu, 17 Jan 2002 16:14:34 +0530 (IST)
From: Vijay Bhaskar A K <vijayak@india.hp.com>
Message-Id: <200201171044.QAA11498@dce.india.hp.com>
Subject: Re: [dhcwg] Comments on 22 rev of the draft
To: rdroms@cisco.com
Date: Thu, 17 Jan 2002 16:14:33 +0530
Cc: vijayak@india.hp.com, Bernie.Volz@am1.ericsson.se, dhcwg@ietf.org
In-Reply-To: <4.3.2.7.2.20020116220059.00b91d18@funnel.cisco.com> from Ralph Droms at Jan "16, " 2002 "10:53:16" pm
X-Mailer: ELM [$Revision: 1.17.214.2 $]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit
See my reply inline. ~Vijay > My thoughts on these issues... > > - Ralph > > At 01:08 PM 1/16/2002 -0600, Bernie Volz (EUD) wrote: > > >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>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. > > > >- I think we need to fix the order of occurence some options that can > >appear in the dhcp messages. I think, the DUID option should occur > >before the IA option. This makes the processing simpler. > > > >BV> I think this would be good to say that a client MUST place the DUID > >option in a mesage before any IA options. > > RD - I'm willing to put in the text, but I don't see how it makes the > processing easier. VB> If DUID occurs before the IA option, then, it will be easier to locate the bindings of the client and then process the IA by IA. > > >- I didn't get, why the authentication option should be the last one. I > >feel like it should be the first one. If the server/client is not able > >to validate the authentication, it can straight away discard the packet > >without further processing. > > > >BV> I too wouldn't mind having this earlier. It makes it easier to > >validate messages since one doesn't have to process all of the options (or > >at least parse to some extent all of the options) before one can > >authenticate the message. But, I would call this a SHOULD not a MUST. > > RD - I'm willing to make this change. > > >v- Section 13 says the ways for selecting addresses for assignment in > >IAs. Assume, the server has got a direct message from the client. The > >IP datagram source address is a site-local one. The message is received > >on the server's interface, which is configured with a global address. > >According to the draft, the server should assume that the client is on > >the link identified by the sitelocal address in datagram. Now, the > >problem arises, if the server is not configured for allocating > >site-local address for the link. Now, can the server assume, since the > >client has sent the direct message, it is on the same link as the server > >and assign it an address of global scope, with the same prefix of its > >received interface. I think, i have already raised the similar kind of > >problem previously, the answer i had got was to select address of global > >scope. Then, the server should not select the link based on the source > >address. This is an implementation problem we faced. FYI, HP has > >officially released DHCPv6. This implementation is based on 16th and > >some portion of 18th version of the draft. This software is freely > >available at <http://software.hp.com/>http://software.hp.com/ You > >can download it and tell me > >your comments. > > > >BV> Section 13 tells how to determine the *LINK* the client is on. Once > >that has been done, you assign addresses based on the prefixes that the > >server has configured for that *LINK*. If the source address for the > >DHCP message was a link local, the server knows that it can't have come > >from anywhere but that link (since link-local are only valid locally). > >But this only determines the LINK for the client; not the addresses. > > RD - To expand on Bernie's response, the server is free to assign > an address according to whatever rules it might be configure with, > once the server has determined the link to which the client is > attached. > > >- Using DUID, how the address selection is done? > > > >BV> I don't understand what you are asking here. > > RD - It's possible to encode a rule for address assignment > based on DUID, which would be what is sometimes called a > "reservation" in some DHCPv4 servers. > > >- The draft says that, when the client needs an additional temporary > >address, it can include OPTION_RTA encapsulated in OPTION_IA and get the > >additional one. This means, in the same IA, any number of addresses can > >be can be added and deleted. Will it hold for normal addresses also? I > >mean, for additional normal addresses, whether the client has to use > >already existing IA to get additional address (or) will it use a fresh > >IA? I remember that, the answer i got for this question 3-4 months back > >was that the client will use fresh IA, because, adding address to the > >same IA will lead complexity. Just in curiosity, i am asking, why this > >complexity was introduced for temporary addresses? Why can't the client > >can ask additional temporary addresses in a fresh IA? > > > >BV> We do NOT want IA explosion. Ideally, a client should be able to use > >the same IA forever under "normal" cases. A IA can have one or many > >addresses, addresses will come and go. Server policy dictates the non- > >temporary addresses assigned to a client. Client policy dictates the > >temporary address needs - hence the client must have a way to say > >"give me more". For example, if a client is running two applications that > >each want unique temporary addresses, it has to request those from the > >server. Later, when a third application starts, the client will need > >another address. > > RD - The complexity comes not so much from adding an address > to an IA as from the semantics of how to request that the > server add a new address to an IA. So, a server can replace > temporary addresses in an IA as lifetimes on existing addresses > expire; if a client wants more addresses, it sends a new IA. VB> We can use similar option like OPT_RTA. If all the additional addresses obtained are added to same IA, then we can do renew in one short. Thus, preventing, multiple renew messages going to server. > > >- Can temporary addresses and normal addresses can co-exist in same IA? > >If yes, then, for renewal, does the client send normal addresses alone > >in IA to the server? since, the renewal of temporary addresses is > >meaningless. > > > >BV> YES the can both be in the SAME IA. That is the intention. > > RD - Agreed. > > >- I thought for decreasing the load of server, unlike DHCPv4, in DHCPv6, > >the dns updates was moved to client. But, the draft says that, for > >temporary addresses, the server has to update the DNS. Why this feature > >was included in server, instead of client? > > > >BV> What we say in section 14 is: > > > > The server MAY update the DNS for a temporary address as described in > > section 4 of RFC3041, and MUST NOT update the DNS in any other way > > for a temporary address. > > > >BV> This all depends how DDNS is handled with DHCPv6 and who is doing the > >updates. We just wanted to be clear that if the server was doing DDNS > >updates for the client, is must adhere to the requirements of RFC 3041 > >in doing them!! > > RD - Registering a temporary address in DNS defeats the anonymity > provided by that address. Clients won't want to register temporary > addresses; a server may register according to the rules > in RFC3041. > > >- Why only temporary has to be updated in DNS? why not normal > >addresses? > > > >BV> See answer to previous question. DDNS updates are still TBD. Likely > >the DHCPv4 FQDN option will be used (changing the A processing to reflect > >AAAA processing and using the DUID for the client identification). > > RD - Agreed. VB> Firstly, in most of the places, i am not able to identify whether you are agreeing my comments or bernie's. > > >- I think for updation, we need to define, hostname/FQDN option for > >this. > > > >BV> Yes, we will need this. > > RD - Agreed. > > >- How can the client specify the number of address it wants? Will it > >send IA optio with 'n' number empty of IA_ADDR option? Instead of that, > >can we define another option OPT_RA similar to OPT_RTA, that can be > >encapsulated in OPT_IA? > > > >BV> The client can't specify how many non-temporary addresses it wants. > >This is controlled by the server. The client *CAN* use multiple IAs and > >if the server policy allows, that can easily be used to give the clients > >LOTS of addresses (one set per IA). > > RD - Agreed. > > >- Section 17.1.2 says that the client collects Advertise messages until > >SOL_TIMEOUT has elapsed. Then, RT will be recalculated. Now, does the > >client needs to retransmit the SOLICIT message? If it is so, then, the > >same server will reply multiple times. But the retransmission algorithm > >in Section 15 says that, it should retransmit the packet. > > > >BV> The client waits SOL_TIMEOUT but it does not retransmit the Solicit > >if it has received at least one Advertise. Retransmit Solicit only if no > >Advertise messages are received. > > RD - Agreed. > > >- In section 17.1.2, we need to add a sentence, "When the RT reached > >MRT, if the one or more valid advertise message is obtained, the client > >should stop sending Advertise message and proceed further with collected > >Advertise message". Otherwise, since MRC and MRD are 0, this process > >will go infinetly according to algorithm specified in Section 15. This > >is also an implementation problem we faced. > > > >BV> Haven't studied this issue. > > RD - I don't understand the way you've explained the issue. If > the client has received an Advertise message, it will terminate > the retransmission process and accept the Advertise message. VB> We need to be more specific. The algorithm in Section 15 says, if MRC and MRD are 0, the transaction is infinite until the reply is obtained. The variation of this algorithm in 17.1.2 says that, the client should be waiting in collecting the advertise messages even if it has received advertise message. And, it does not say at what time, the client should stop collecting the advertise message. So, this text has to be added. > > >- In some place, the server should fill "server-address" with one of its > >address based on the link in which the packet is received. In another > >place, it is said that the server-address field can be filled with the > >address configured by the administrator. What is the standard procedure > >to be followed? > > > >BV> We probably should clean up the text to be consistent. I think the > >answer is use configured address if so configured for that LINK, otherwise > >use one of the LINK interface addresses. > > RD - OK... > > >- In Advertise, should the server assign all the addresses asked by the > >client? (or) only few of them? > > > >BV> It depends on the server's policies. > > RD - Agreed. > > >- 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. > > RD - Agreed; the intention is that the Advertise message is > advisory and not a firm promise of addresses to be assigned to > the client. VB> Please refer my reply to bernie's mail... > > >- If the server has fewer addresses than the client has asked, will the > >server assign fewer addresses or send AddrUnavail? > > > >BV> I would only return AddrUnavail if NO addresses are available. If you > >can assign some, give the client those. It can make a decisions as to > >whether it wants to accept them or not. > > RD - Agreed. > > >- The draft says that the renew message can be used for checking up the > >validity of the other configuration parameters. For checking the > >validity of them, will the client send the option codes in ORO option > >(or) send the parameters in their respective options? > > > >BV> The Renew message does not need to include those options (including > >them in an ORO is probably a good idea so the server knows you want them). > >It is really the Reply that matters and the server will Reply with the > >current settings. The client can then apply those values. The server will > >(I suspect) not really check them - it just Replies with the current > >values. > > RD - Agreed. > > >- Should release/decline of addresses be done for IA as whole? (or) Can > >few addresses be relased from an IA? (partial release) > > > >BV> Individual addresses can be released or declined. The client MUST > >include the addresses to decline/release. The server ignores any addresses > >that the client doesn't "own". > > RD - Agreed. > > >- Assuming the client is sending multiple IAs for renewing, the server > >finds that one particular IA is not found in the client bindings, will > >it renews the remaining IAs? (or) will it send NoBinding error? > > > >BV> It can send a NoBinding status for that IA. (And renew the others.) > > RD - Agreed. > > >- What will the client do, for the multiple IAs sent for renew, only one > >IA is missing in the reply? > > > >BV> No sure what you asking? Is this a follow up to the previous question? > >If the IA returns with a NoBinding status, the client may either continue > >to use those addresses (since it must have gotten them from someone in the > >past) or drop them (and the IA). > > RD - I agree; the client can continue to use the addresses in the > un-Renew-ed IA until the lifetimes for those addresses expire. > > >- Can you explain the differnce between, "configuration information are > >not valid" and "configuration information does not match". In the first > >case, for Confirm message ConfNoMatch is sent and for the next one, it > >is sending SUCCESS. The draft says that for ConfNoMatch, the client > >should send renew message. If the configuration parameters are not > >matching, then what is the use of sending renew message? > > > >BV> Have to look into this one more. > > > >- For the cases like, "conf parameters are not valid", "conf parameters > >does not match" and "prefix does not match", what will the server do, > >for the release message? What will the server do? if (i) all, (ii) only > >few addresses are invalid. Will the server release the address which > >are valid? > > > >BV> Have to look into this one more. > > > >- Section 21.6.5.5 says that, if the client is not able to validate the > >authentication for the REPLY message, then it should start with the > >SOLICIT. I feel that this is inefficient, instead, it can try the next > >available server which has sent the advertise message. > > > >BV> Have to look into this one more. > > > >- In the previous versions, we have Retransmission Parameter option. > >Why it was removed? > > > >BV> There are significant security / DOS issues with allowing the server > >to set parameters. Also, there are issues as when these parameters are to > >be used (vs the defaults). If a client moves to a completely different > >DHCP domain, the parameters may not be valid and how does it know that? > > RD - Agreed; in fact, when a client moves to a new link (which is > the case in which the Retransmission Parameter option would be used > to change the client's behavior for the new link), it's too late > because the client has potentially already used the retransmission > mechanism on the new link, using the parameters from the old link. > > >- Some useful options were defined in DHCPv6 extension draft. When will > >those options be included in this draft? > > > >BV> Suggest the ones you want to have included! Provide the text (if it > >needs to be revised). That's what Ralph (as editor) has requested in the > >past. > > RD - Please do send requests for other options. > > >I have found some typos in the draft. > > > >- In section 7.3, for reconfigure message, the client should intiate, > >Renew/Reply not the Request/Reply > > > >- In 19.2, it is saying that, for Inform message, all the IAs to be > >included. This a simple cut-paste problem. > > > >- 19.3.4 says, "The client uses the same variables and retransmission > >algorithm as it does with Rebind or Information....". It should be > >"Renew or Information..." > > > >- In 22.14, the server address field in Server Unicast Option is missing. > > > >- In 22.19, User class option message format looks messy, because of > >some sentences in between. > > RD - I'll fix these in the -23 rev of the draft. > > > >Regards > >Vijay > > > >-- > >____Vijay_Bhaskar_A_K____ > >________HP_ESDI__________ > >___Ph:_91_080_2051424____ > >____<Telnet:_847_1424_____>Telnet:_847_1424_____ > >___Pager:_9624_371137____ > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > ><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ______Ph:_2051424________ ____Telnet:_847_1424_____ ___Pager:_9624_371137____ _______________________________________________ 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