From dhcwg-admin@ietf.org Sat Sep 1 08:07:12 2001 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 IAA12776; Sat, 1 Sep 2001 08:07:11 -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 IAA23161; Sat, 1 Sep 2001 08:06:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23139 for ; Sat, 1 Sep 2001 08:06:05 -0400 (EDT) Received: from mail.span.ch (mail.span.ch [144.85.10.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12718 for ; Sat, 1 Sep 2001 08:04:42 -0400 (EDT) Received: from is-production.com (unknown [144.85.4.122]) by mail.span.ch (Postfix) with ESMTP id 311B7387FC; Sat, 1 Sep 2001 14:06:02 +0200 (MEST) Message-ID: <3B90CD13.8185CF4@is-production.com> 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 Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Re: DHCP behind NAT References: <200108311654.f7VGslj00311@grosse.bisbee.fugue.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Hello, 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 : http://www.is-pronet.com/download/dhcp-3.0rc11_NAT_patch.tar.gz 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 mailto:bernard.dugas@is-production.com | | 30 Rue Auguste Piccard Tel.: +33 450 205 105 | | FR 01630 St Genis Pouilly Fax : +33 450 205 106 | |_________________________________________________________________| _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 1 09:32:32 2001 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 ; 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 ; 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 cc: dhcwg@ietf.org Subject: Re: [dhcwg] Re: DHCP behind NAT In-Reply-To: Message from Bernard Dugas 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: 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 From dhcwg-admin@ietf.org Tue Sep 4 07:00:34 2001 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 HAA07529; Tue, 4 Sep 2001 07:00:33 -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 GAA20203; Tue, 4 Sep 2001 06:59:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20176 for ; Tue, 4 Sep 2001 06:59:15 -0400 (EDT) Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07485 for ; Tue, 4 Sep 2001 06:57:50 -0400 (EDT) Received: from postbox.india.hp.com (postbox.india.hp.com [15.10.45.1]) by atlrel7.hp.com (Postfix) with ESMTP id AC6641F59B for ; Tue, 4 Sep 2001 06:57:12 -0400 (EDT) Received: from india.hp.com (bansal@tohfa.india.hp.com [15.10.44.199]) by postbox.india.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id QAA27715 for ; Tue, 4 Sep 2001 16:35:21 +0530 (IST) Message-ID: <3B94B3A5.59DAAC3B@india.hp.com> Date: Tue, 04 Sep 2001 16:27:42 +0530 From: AJAY BANSAL Organization: HP-ISO X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] doubt in rfc 3046 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Can anyone help in this: In a client's dhcp request, which a DHCP server recieves, can both, the 'client id' option as well as the 'remote client id' (relay agent sub-option) be present? If yes, then will there be any significance of client id field in such cases, since client is not a trustworthy component? Is it must for the server to copy the client id back in its reply? with regards Ajay Bansal. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 4 09:23:16 2001 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 JAA14644; Tue, 4 Sep 2001 09:23:12 -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 JAA24230; Tue, 4 Sep 2001 09:20:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24210 for ; Tue, 4 Sep 2001 09:20:40 -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 JAA14378 for ; Tue, 4 Sep 2001 09:19:15 -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 f84DEbf24790; Tue, 4 Sep 2001 06:14:37 -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 f84DKFH00427; Tue, 4 Sep 2001 09:20:15 -0400 (EDT) Message-Id: <200109041320.f84DKFH00427@grosse.bisbee.fugue.com> To: AJAY BANSAL cc: dhcwg@ietf.org Subject: Re: [dhcwg] doubt in rfc 3046 In-Reply-To: Message from AJAY BANSAL of "Tue, 04 Sep 2001 16:27:42 +0530." <3B94B3A5.59DAAC3B@india.hp.com> Date: Tue, 04 Sep 2001 09:20:15 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > In a client's dhcp request, which a DHCP server > recieves, can both, > the 'client id' option as well as the 'remote > client id' > (relay agent sub-option) be present? The DHCP client never sends a relay agent information option. So if you are implementing a client, the answer to your question is "no, never." If you are implementing a relay agent, it's "yes," but the remote-id is intended to refer to a remote link, not to an individual client. The client-id and remote-id fields are completely unrelated. > If yes, then will there be any significance of > client id field in such cases, > since client is not a trustworthy component? The client isn't trustworthy, but hopefully the relay agent is. The client id identifies the client, so you just have to trust that the client is telling the truth. > Is it must for the server to copy the client id > back in its reply? I don't think so, but you should refer to the RFC to be sure. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 4 16:30:36 2001 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 QAA26984; Tue, 4 Sep 2001 16:30:35 -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 QAA06583; Tue, 4 Sep 2001 16:27:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06551 for ; Tue, 4 Sep 2001 16:27:37 -0400 (EDT) Received: from extmail01m.raleigh.ibm.com (extmail01.raleigh.ibm.com [204.146.167.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26880 for ; Tue, 4 Sep 2001 16:26:11 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [192.168.1.107]) by extmail01m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id QAA19022 for ; Tue, 4 Sep 2001 16:27:07 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id QAA33934 for ; Tue, 4 Sep 2001 16:27:06 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA30257 for ; Tue, 4 Sep 2001 16:21:14 -0400 Message-Id: <200109042021.QAA30257@rotala.raleigh.ibm.com> To: dhcwg@ietf.org In-Reply-To: Message of "Mon, 27 Aug 2001 21:12:05 EDT." <200108280112.f7S1C6T00354@grosse.bisbee.fugue.com> Date: Tue, 04 Sep 2001 16:21:13 -0400 From: Thomas Narten Subject: [dhcwg] How to encode DNS labels in DHCP options Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The document draft-ietf-dhc-fqdn-option-02.txt is apparently in WGLC. I note that this document uses the following encoding to encode the DNS name: The data in the Domain Name field may appear in one of two formats: ASCII, or DNS-style binary encoding (without compression, of course), as described in RFC1035[3]. A client which sends the FQDN option MUST set the "E" bit to indicate that the data in the Domain Name field is DNS binary encoded. If a server receives an FQDN option from a client, and intends to include an FQDN option in its reply, it MUST use the same encoding that the client used. The DNS encoding is recommended. The use of ASCII-encoded domain-names is fragile, and the use of ASCII encoding in this option should be considered deprecated. What does it mean for ascii to be deprecated, when the previous text says it MUST be supported. Is this trying to document some behavior (from an earlier ID) that has been implemented and deployed? (If so, it might be good to actually come out and say that). Or, given that this is an ID, not an update to an existing RFC, seems like if you don't want to allow ascii, the document should simply not support it at all. What is the document really telling implementors regarding what they should implement? As a comparison point, draft-aboba-dhc-domsearch-06.txt doesn't allow ascii, it just uses the on-the-wire binary encoding. Finally, I'll note that I recently took the message back to the author of draft-ietf-sip-dhcp-04.txt that said they shouldn't be using ascii (see appended note). Was that in error? I'd like to see some clarification on this seeming inconsistancy. What is the WG's position with regards to the how DHCP options should be encoding DNS labels? Thomas From: Thomas Narten To: Henning Schulzrinne cc: Allison Mankin , "Ralph E. Droms" Date: Mon, 27 Aug 2001 11:49:39 -0400 Subject: draft-ietf-sip-dhcp-04.txt Hi Henning. I'd like to restart discussion on the sip-dhcp document. The meeting minutes from Minneapolis include: > This is from the minutes of the DHC WG meeting in Minnesota. > > DHCP Option for SIP Servers Henning Schulzrinne, 20 minutes > http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-dhcp-04.txt > > The WG finds this option acceptable in principle; however, the > specific format and encoding of data in the option is still an issue. > Authors want simple ASCII text encoding of DNS name or dotted decimal > IP address; WG recommends RFC1035 encoding for DNS name and binary > encoding of IP address with flag to indicate which encoding is in use. > WG has selected RFC1035 for other recent options. The last two sentences are the ones that are key. draft-ietf-sip-dhcp-04.txt currently says: The SIP server DHCP option carries a DNS (RFC 1035 [6]) fully- qualified domain name to be used by the SIP client to locate a SIP server. The FQDN is 16-bit Unicode text encoded into an octet stream using UTF-8 (RFC 2044 [7]). The FQDN in the SIP server option MUST NOT be null-terminated. It MUST NOT end with a period. and then later: It is possible, but NOT RECOMMENDED that the string is the textual representation of a network address, e.g., a "dotted quad" for IPv4 and the hexadecimal representation of RFC 2373 [8]. Implementations MUST detect this case by checking whether all characters are decimal digits or periods. This is, of course, in contrast to what the DHC WG is recommending. Are there any issues with just going along with the DHC WG recommendation? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 4 16:41:23 2001 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 QAA27408; Tue, 4 Sep 2001 16:41:23 -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 QAA07070; Tue, 4 Sep 2001 16:38:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07041 for ; Tue, 4 Sep 2001 16:38:26 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27313 for ; Tue, 4 Sep 2001 16:37:00 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f84KcQp22483 for ; Tue, 4 Sep 2001 15:38:26 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f84KcPW19609 for ; Tue, 4 Sep 2001 15:38:25 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Sep 04 15:38:25 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 15:38:24 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B351A@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] How to encode DNS labels in DHCP options Date: Tue, 4 Sep 2001 15:38:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13581.879DBEC0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13581.879DBEC0 Content-Type: text/plain; charset="iso-8859-1" Thomas: The problem is that the FQDN option is already in such wide deployment with the ASCII encoding that it would be impossible to ask that everyone change to using the new. This ID just took too long and people went ahead and implement it (especially since the option id was already assigned). So, the solution is to document this behavoir and find a way to support the new proper behavoir in a backward compatible way. And then also to indicate that this old method should not be used. Note that I think it should be "SHOULD be consider deprecated." So, I think the wording in the document is correct and should basically stay that way. Perhaps the historical perspective needs to be added? - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@raleigh.ibm.com] Sent: Tuesday, September 04, 2001 4:21 PM To: dhcwg@ietf.org Subject: [dhcwg] How to encode DNS labels in DHCP options The document draft-ietf-dhc-fqdn-option-02.txt is apparently in WGLC. I note that this document uses the following encoding to encode the DNS name: The data in the Domain Name field may appear in one of two formats: ASCII, or DNS-style binary encoding (without compression, of course), as described in RFC1035[3]. A client which sends the FQDN option MUST set the "E" bit to indicate that the data in the Domain Name field is DNS binary encoded. If a server receives an FQDN option from a client, and intends to include an FQDN option in its reply, it MUST use the same encoding that the client used. The DNS encoding is recommended. The use of ASCII-encoded domain-names is fragile, and the use of ASCII encoding in this option should be considered deprecated. What does it mean for ascii to be deprecated, when the previous text says it MUST be supported. Is this trying to document some behavior (from an earlier ID) that has been implemented and deployed? (If so, it might be good to actually come out and say that). Or, given that this is an ID, not an update to an existing RFC, seems like if you don't want to allow ascii, the document should simply not support it at all. What is the document really telling implementors regarding what they should implement? As a comparison point, draft-aboba-dhc-domsearch-06.txt doesn't allow ascii, it just uses the on-the-wire binary encoding. Finally, I'll note that I recently took the message back to the author of draft-ietf-sip-dhcp-04.txt that said they shouldn't be using ascii (see appended note). Was that in error? I'd like to see some clarification on this seeming inconsistancy. What is the WG's position with regards to the how DHCP options should be encoding DNS labels? Thomas From: Thomas Narten To: Henning Schulzrinne cc: Allison Mankin , "Ralph E. Droms" Date: Mon, 27 Aug 2001 11:49:39 -0400 Subject: draft-ietf-sip-dhcp-04.txt Hi Henning. I'd like to restart discussion on the sip-dhcp document. The meeting minutes from Minneapolis include: > This is from the minutes of the DHC WG meeting in Minnesota. > > DHCP Option for SIP Servers Henning Schulzrinne, 20 minutes > http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-dhcp-04.txt > > The WG finds this option acceptable in principle; however, the > specific format and encoding of data in the option is still an issue. > Authors want simple ASCII text encoding of DNS name or dotted decimal > IP address; WG recommends RFC1035 encoding for DNS name and binary > encoding of IP address with flag to indicate which encoding is in use. > WG has selected RFC1035 for other recent options. The last two sentences are the ones that are key. draft-ietf-sip-dhcp-04.txt currently says: The SIP server DHCP option carries a DNS (RFC 1035 [6]) fully- qualified domain name to be used by the SIP client to locate a SIP server. The FQDN is 16-bit Unicode text encoded into an octet stream using UTF-8 (RFC 2044 [7]). The FQDN in the SIP server option MUST NOT be null-terminated. It MUST NOT end with a period. and then later: It is possible, but NOT RECOMMENDED that the string is the textual representation of a network address, e.g., a "dotted quad" for IPv4 and the hexadecimal representation of RFC 2373 [8]. Implementations MUST detect this case by checking whether all characters are decimal digits or periods. This is, of course, in contrast to what the DHC WG is recommending. Are there any issues with just going along with the DHC WG recommendation? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C13581.879DBEC0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] How to encode DNS labels in DHCP options

Thomas:

The problem is that the FQDN option is already in such wide deployment with
the ASCII encoding that it would be impossible to ask that everyone change
to using the new. This ID just took too long and people went ahead and
implement it (especially since the option id was already assigned). So, the
solution is to document this behavoir and find a way to support the new
proper behavoir in a backward compatible way. And then also to indicate that
this old method should not be used.

Note that I think it should be "SHOULD be consider deprecated."

So, I think the wording in the document is correct and should basically stay
that way. Perhaps the historical perspective needs to be added?

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@raleigh.ibm.com]
Sent: Tuesday, September 04, 2001 4:21 PM
To: dhcwg@ietf.org
Subject: [dhcwg] How to encode DNS labels in DHCP options


The document draft-ietf-dhc-fqdn-option-02.txt is apparently in
WGLC. I note that this document uses the following encoding to encode
the DNS name:

   The data in the Domain Name field may appear in one of two formats:
   ASCII, or DNS-style binary encoding (without compression, of
   course), as described in RFC1035[3]. A client which sends the FQDN
   option MUST set the "E" bit to indicate that the data in the Domain
   Name field is DNS binary encoded. If a server receives an FQDN
   option from a client, and intends to include an FQDN option in its
   reply, it MUST use the same encoding that the client used. The DNS
   encoding is recommended. The use of ASCII-encoded domain-names is
   fragile, and the use of ASCII encoding in this option should be
   considered deprecated.

What does it mean for ascii to be deprecated, when the previous text
says it MUST be supported. Is this trying to document some behavior
(from an earlier ID) that has been implemented and deployed? (If so,
it might be good to actually come out and say that).

Or, given that this is an ID, not an update to an existing RFC, seems
like if you don't want to allow ascii, the document should simply not
support it at all. What is the document really telling implementors
regarding what they should implement?

As a comparison point, draft-aboba-dhc-domsearch-06.txt doesn't allow
ascii, it just uses the on-the-wire binary encoding.

Finally, I'll note that I recently took the message back to the author
of draft-ietf-sip-dhcp-04.txt that said they shouldn't be using ascii
(see appended note). Was that in error?

I'd like to see some clarification on this seeming inconsistancy. What
is the WG's position with regards to the how DHCP options should be
encoding DNS labels?

Thomas

From: Thomas Narten <narten@rotala.raleigh.ibm.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Allison Mankin <mankin@ISI.EDU>,
    "Ralph E. Droms" <droms@bucknell.edu>
Date: Mon, 27 Aug 2001 11:49:39 -0400
Subject: draft-ietf-sip-dhcp-04.txt

Hi Henning.

I'd like to restart discussion on the sip-dhcp document. The meeting
minutes from Minneapolis include:

> This is from the minutes of the DHC WG meeting in Minnesota.
>
>    DHCP Option for SIP Servers                Henning Schulzrinne, 20 minutes
>    http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-dhcp-04.txt
>
>    The WG finds this option acceptable in principle; however, the
>    specific format and encoding of data in the option is still an issue.
>    Authors want simple ASCII text encoding of DNS name or dotted decimal
>    IP address; WG recommends RFC1035 encoding for DNS name and binary
>    encoding of IP address with flag to indicate which encoding is in use.
>    WG has selected RFC1035 for other recent options.

The last two sentences are the ones that are key.

draft-ietf-sip-dhcp-04.txt currently says:


   The SIP server DHCP option carries a DNS (RFC 1035 [6]) fully-
   qualified domain name to be used by the SIP client to locate a SIP
   server. The FQDN is 16-bit Unicode text encoded into an octet stream
   using UTF-8 (RFC 2044 [7]). The FQDN in the SIP server option MUST
   NOT be null-terminated. It MUST NOT end with a period.

and then later:

   It is possible, but NOT RECOMMENDED that the string is the textual
   representation of a network address, e.g., a "dotted quad" for IPv4
   and the hexadecimal representation of RFC 2373 [8].  Implementations
   MUST detect this case by checking whether all characters are decimal
   digits or periods.

This is, of course, in contrast to what the DHC WG is recommending.

Are there any issues with just going along with the DHC WG
recommendation?

Thomas


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

------_=_NextPart_001_01C13581.879DBEC0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 4 17:17:28 2001 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 RAA28204; Tue, 4 Sep 2001 17:17:27 -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 RAA08107; Tue, 4 Sep 2001 17:14:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19844 for ; Tue, 4 Sep 2001 06:50:01 -0400 (EDT) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07326 for ; Tue, 4 Sep 2001 06:48:36 -0400 (EDT) Received: from atlrel6.hp.com (atlrel6.hp.com [192.151.27.8]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f84Anwq32487 for ; Tue, 4 Sep 2001 06:49:58 -0400 (EDT) Received: from postbox.india.hp.com (postbox.india.hp.com [15.10.45.1]) by atlrel6.hp.com (Postfix) with ESMTP id EABB11F7F4 for ; Tue, 4 Sep 2001 06:49:32 -0400 (EDT) Received: from india.hp.com (bansal@tohfa.india.hp.com [15.10.44.199]) by postbox.india.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id QAA26198 for ; Tue, 4 Sep 2001 16:26:09 +0530 (IST) Message-ID: <3B94B17D.B6751E32@india.hp.com> Date: Tue, 04 Sep 2001 16:18:29 +0530 From: AJAY BANSAL Organization: HP-ISO X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: "dhcp-v4@bucknell.edu" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] doubt in rfc 3046 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Can anyone help in this: In a client's dhcp request, which a DHCP server recieves, can both, the 'client id' option as well as the 'remote client id' (relay agent sub-option) be present? If yes, then will there be any significance of client id field in such cases, since client is not a trustworthy component? Is it must for the server to copy the client id back in its reply? with regards Ajay Bansal. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 4 17:30:57 2001 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 RAA28574; Tue, 4 Sep 2001 17:30:57 -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 RAA08727; Tue, 4 Sep 2001 17:27:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08702 for ; Tue, 4 Sep 2001 17:27:50 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28477 for ; Tue, 4 Sep 2001 17:26:24 -0400 (EDT) Received: from mjs-nt.cisco.com ([172.27.181.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA18037; Tue, 4 Sep 2001 17:27:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20010904170432.02ac0330@funnel.cisco.com> X-Sender: mjs@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Sep 2001 17:27:19 -0400 To: Thomas Narten From: Mark Stapp Subject: Re: [dhcwg] How to encode DNS labels in DHCP options Cc: dhcwg@ietf.org In-Reply-To: <200109042021.QAA30257@rotala.raleigh.ibm.com> References: 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: X-BeenThere: dhcwg@ietf.org Thomas, I think it's clear to us that we should specify DNS encoding for domain names carried in DHCP options. As Bernie noted, there's a historical problem in this case that makes it unusually painful to remove text about the ASCII behavior entirely. We don't want new clients to implement the deprecated behavior, but we need to describe it for the benefit of new server implementations which will encounter old clients for a long time to come. The draft has evolved to try to accomodate the situation, but I can understand that it hasn't cleared up the confusion. I've tried to revise a couple of sections in the document to make this situation and its roots clearer. Client implementations are directed to use the dns-encoding. Server implementors are advised of the deprecated client behavior, which is described in a new section alongside the specification of the Domain Name field. This is the revised text from section 4.1, describing the use of the "E" flag: The data in the Domain Name field SHOULD appear in DNS-style binary encoding (without compression, of course), as described in RFC1035[3]. A client which sends the FQDN option SHOULD use this encoding. The client MUST set the "E" bit when the data in the Domain Name field is in DNS binary encoding. If a server receives an FQDN option from a client, and intends to include an FQDN option in its reply, it MUST use the same encoding that the client used, and MUST set the "E" bit accordingly. Server implementors should note that earlier draft versions of this specification permitted an ASCII encoding of the domain name. Clients which implemented this encoding were deployed before this specification was completed. Server implementors which need to support these clients should note the section on the deprecated ASCII encoding (Section 4.3.1). And this is the revised text from section 4.3, describing the Domain Name field: 4.3 The Domain Name Field The Domain Name part of the option carries all or part of the FQDN of a DHCP client. The data in the Domain Name field SHOULD appear in uncompressed DNS encoding as specified in RFC1035[3]. If the DHCP client uses DNS encoding, it MUST set the third bit in the Flags field (the "E" bit). A client may be configured with a fully-qualified domain name, or with a partial name that is not fully-qualified. If a client knows only part of its name, it MAY send a name that is not fully-qualified, indicating that it knows part of the name but does not necessarily know the zone in which the name is to be embedded. A client which wants to convey part of its FQDN sends a non-terminal sequence of labels in the Domain Name part of the option. Clients and servers should assume that the the name field contains a fully-qualified name unless this partial-name format exists. 4.3.1 Deprecated ASCII Encoding The DNS encoding specified above MUST be supported by DHCP servers. However, a substantial population of clients implemented an earlier version of this specification, which permitted an ASCII encoding of the Domain Name field. Server implementations should be aware that clients which send the FQDN option with the "E" bit clear are using an ASCII version of the Domain Name field. Servers MAY be prepared to return an ASCII encoded version of the Domain Name field to such clients. The use of ASCII encoding in this option should be considered deprecated. A DHCP client which used ASCII encoding was permitted to suggest a single label if it was not configured with a fully-qualified name. Such clients send a single label as a series of ASCII characters in the Domain Name field, excluding the "." (dot) character. Such clients SHOULD follow the character-set recommendations of RFC1034[2] and RFC1035[3]. Does this help? Is this too much change, or the right amount? Is there anything that's still unclear after these changes? -- Mark At 04:21 PM 9/4/01 -0400, Thomas Narten wrote: >The document draft-ietf-dhc-fqdn-option-02.txt is apparently in >WGLC. I note that this document uses the following encoding to encode >the DNS name: > > The data in the Domain Name field may appear in one of two formats: > ASCII, or DNS-style binary encoding (without compression, of > course), as described in RFC1035[3]. A client which sends the FQDN > option MUST set the "E" bit to indicate that the data in the Domain > Name field is DNS binary encoded. If a server receives an FQDN > option from a client, and intends to include an FQDN option in its > reply, it MUST use the same encoding that the client used. The DNS > encoding is recommended. The use of ASCII-encoded domain-names is > fragile, and the use of ASCII encoding in this option should be > considered deprecated. > >What does it mean for ascii to be deprecated, when the previous text >says it MUST be supported. Is this trying to document some behavior >(from an earlier ID) that has been implemented and deployed? (If so, >it might be good to actually come out and say that). > >Or, given that this is an ID, not an update to an existing RFC, seems >like if you don't want to allow ascii, the document should simply not >support it at all. What is the document really telling implementors >regarding what they should implement? > >As a comparison point, draft-aboba-dhc-domsearch-06.txt doesn't allow >ascii, it just uses the on-the-wire binary encoding. > >Finally, I'll note that I recently took the message back to the author >of draft-ietf-sip-dhcp-04.txt that said they shouldn't be using ascii >(see appended note). Was that in error? > >I'd like to see some clarification on this seeming inconsistancy. What >is the WG's position with regards to the how DHCP options should be >encoding DNS labels? > >Thomas > >From: Thomas Narten >To: Henning Schulzrinne >cc: Allison Mankin , > "Ralph E. Droms" >Date: Mon, 27 Aug 2001 11:49:39 -0400 >Subject: draft-ietf-sip-dhcp-04.txt > >Hi Henning. > >I'd like to restart discussion on the sip-dhcp document. The meeting >minutes from Minneapolis include: > > > This is from the minutes of the DHC WG meeting in Minnesota. > > > > DHCP Option for SIP Servers Henning Schulzrinne, 20 > minutes > > http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-dhcp-04.txt > > > > The WG finds this option acceptable in principle; however, the > > specific format and encoding of data in the option is still an issue. > > Authors want simple ASCII text encoding of DNS name or dotted decimal > > IP address; WG recommends RFC1035 encoding for DNS name and binary > > encoding of IP address with flag to indicate which encoding is in use. > > WG has selected RFC1035 for other recent options. > >The last two sentences are the ones that are key. > >draft-ietf-sip-dhcp-04.txt currently says: > > > The SIP server DHCP option carries a DNS (RFC 1035 [6]) fully- > qualified domain name to be used by the SIP client to locate a SIP > server. The FQDN is 16-bit Unicode text encoded into an octet stream > using UTF-8 (RFC 2044 [7]). The FQDN in the SIP server option MUST > NOT be null-terminated. It MUST NOT end with a period. > >and then later: > > It is possible, but NOT RECOMMENDED that the string is the textual > representation of a network address, e.g., a "dotted quad" for IPv4 > and the hexadecimal representation of RFC 2373 [8]. Implementations > MUST detect this case by checking whether all characters are decimal > digits or periods. > >This is, of course, in contrast to what the DHC WG is recommending. > >Are there any issues with just going along with the DHC WG >recommendation? > >Thomas > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 4 18:06:07 2001 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 SAA29319; Tue, 4 Sep 2001 18:06:06 -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 RAA09723; Tue, 4 Sep 2001 17:58:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09698 for ; Tue, 4 Sep 2001 17:58:11 -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 RAA29103 for ; Tue, 4 Sep 2001 17:56:44 -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 f84Lw9f25575; Tue, 4 Sep 2001 14:58:09 -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 f84Lw4s00342; Tue, 4 Sep 2001 17:58:04 -0400 (EDT) Message-Id: <200109042158.f84Lw4s00342@grosse.bisbee.fugue.com> To: Thomas Narten cc: dhcwg@ietf.org Subject: Re: [dhcwg] How to encode DNS labels in DHCP options In-Reply-To: Message from Thomas Narten of "Tue, 04 Sep 2001 16:21:13 EDT." <200109042021.QAA30257@rotala.raleigh.ibm.com> Date: Tue, 04 Sep 2001 17:58:04 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The idea of using the RFC1035 encoding is that it is exactly what the DNS protocol currently specifies. This means that if we use this format, we don't have to worry that it will be our fault that the encoding doesn't work. When IDN happens, it will presumably work on top of the existing packet format, so that means that what we have specified should also work. So IMHO any new DHCP option that contains a domain name should use the RFC1035 format. I can't remember the details with SIP, but I *think* that what is being encoded is not a domain name, and that is the reason for the difference. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 4 21:54:10 2001 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 VAA03071; Tue, 4 Sep 2001 21:54:10 -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 VAA14965; Tue, 4 Sep 2001 21:49:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14894 for ; Tue, 4 Sep 2001 21:49:50 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03001 for ; Tue, 4 Sep 2001 21:48:22 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-2.cisco.com [10.82.240.2]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA07367 for ; Tue, 4 Sep 2001 21:49:16 -0400 (EDT) Message-Id: <4.3.2.7.2.20010904214019.00b7fad0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Sep 2001 21:49:01 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] DHCPv6 spec text for retransmission Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Here is the new text in the DHCPv6 spec describing the transmission and retransmission mechanism for client messages. Thanks to Ted for writing the first draft of this text. Notes: * I chose +-0.0625 (2^-4) as the limits on the randomization factor to (potentially) make the arithmetic a little easier. Perhaps I misspent too much of my youth writing 8080 assembler code and it's just not important to worry about setting those limits around powers of two. If +-0.1 makes more sense, that's fine with me. * I did not choose to base the server Reconfigure-init retransmission mechanism on section 13. I don't think the DHCPv6 spec needs to dictate the behavior of the server when retransmitting Reconfigure-init messages. * There are some references to the use of IAs; the new IA text has not been finalized and does not yet appear in the doc. Please review this new text and reply with comments... - Ralph 7.5. Configuration Variables This section presents a table of client and server configuration variables and the default or initial values for these variables. The client-specific variables MAY be configured on the server and MAY be delivered to the client through the "DHCP Retransmission Parameter Option" in a Reply message. Parameter Default Description ------------------------------------- MIN_SOL_DELAY 1 MIN (secs) to delay 1st mesg MAX_SOL_DELAY 5 MAX (secs) to delay 1st mesg ADV_TIMEOUT 500 SOL Retrans timer (msecs) ADV_MAX_RT 30 MAX timer value (secs) SOL_MAX_ATTEMPTS 0 MAX attempts (0 = infinite) REP_TIMEOUT 250 Retrans timer (msecs) for Reply REP_MAX_RT 0 MAX Retrans time (0 = infinite) REQ_MAX_ATTEMPTS 10 MAX Request/Confirm/Renew/Rebind attempts REL_MSG_ATTEMPTS 5 MAX Release/Decline attempts SRVR_PREF_WAIT 2 Advertise Collect timer (secs) 13. Reliability of Client Initiated Message Exchanges DHCP clients are responsible for reliable delivery of messages in the client-initiated message exchanges described in sections 14 and 15. If a DHCP client fails to receive an expected response from a server, the client must retransmit its message. This section describes the retransmission strategy to be used by clients in client-initiated message exchanges. The client begins the message exchange by transmitting a message to the server. The message exchange terminates when either the client successfully receives the appropriate response or responses from a server or servers, or when the message exchange is considered to have failed according to the retransmission mechanism described below. The client retransmission behavior is controlled and describe by five variables: RT Retransmission timeout IRT Initial retransmission time MRC Maximum retransmission count MRT Maximum retransmission time MRD Maximum retransmission duration RAND Randomization factor With each message transmission or retransmission, the client sets RT according to the rules given below. If RT expires before the message exchange terminates, the client recomputes RT and retransmits the message. Each of the computations of a new RT include a randomization factor (RAND), which is a random number chosen with a uniform distribution between -0.0625 and +0.0625. The randomization factor is included to minimize synchronization of messages transmitted by DHCP clients. The algorithm for choosing a random number does not need to be cryptographically sound. The algorithm SHOULD produce a different sequence of numbers from each invocation of the DHCP client. RT for the first message transmission is based on IRT: RT = IRT + RAND*IRT RT for each subsequent message transmission is based on the previous value of RT: RT = RTprev + RAND*RTprev MRT specifies an upper bound on the value of RT. If MRT has a value of 0, there is no upper limit on the value of RT. Otherwise: if (RT > MRT) RT = MRT + RAND*MRT MRC specifies an upper bound on the number of times a client may retransmit a message. If MRC has a value of 0, the client MUST continue to retransmit the original message until a response is received. Otherwise, the message exchange fails if the client attempts to transmit the original message more than MRC times. MRD specifies an upper bound on the length of time a client may retransmit a message. If MRD has a value of 0, the client MUST continue to retransmit the original message until a response is received. Otherwise, the message exchange fails if the client attempts to transmit the original message more than MRD seconds. 14. DHCP Server Solicitation This section describes how a client locates servers. The behavior of client and server implementations is discussed, along with the messages they use. [...] 14.3. Client Behavior A client uses the Solicit message to discover DHCP servers configured to serve addresses on the link to which the client is attached. 14.3.1. Creation of Solicit messages The client sets the "msg-type" field to SOLICIT. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client includes a DUID option to identify itself to the server. The client MUST include options for any IAs to which it wants the server to assign addresses. The client may include addresses in the IAs as a hint to the server about addresses for which the client may have a preference. The client MAY include an Option Request Option in the Solicit message. The client MUST NOT include any other options except those specifically allowed as defined by specific options. 14.3.2. Transmission of Solicit Messages The client sends the Solicit message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client's first Solicit message on the interface MUST be delayed by a random amount of time between MIN_SOL_DELAY and MAX_SOL_DELAY. This random delay desynchronizes clients which start at the same time (e.g., after a power outage). The client transmits the message according to section 13, using the following parameters: IRT ADV_TIMEOUT MRC SOL_MAX_ATTEMPTS MRT ADV_MAX_RT MRD 0 The mechanism in section 13 is modified as follows for use in the transmission of Solicit messages. The message exchange is not terminated by the receipt of an Advertise before ADV_MSG_TIMEOUT has elapsed. Rather, the client collects Advertise messages until ADV_MSG_TIMEOUT has elapsed. The first RT MUST be selected to be strictly greater than ADV_MSG_TIMEOUT by choosing RAND to be strictly greater than 0. A DHCP client SHOULD choose MRC and MRT to be 0. If the DHCP client is otherwise configured, it MUST stop trying to configure the interface if the message exchange fails. After the DHCP client stops trying to configure the interface, it MAY choose to restart the reconfiguration process after some external event, such as user input, system restart, or when the client is attached to a new link. 14.3.3. Receipt of Advertise messages A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP Solicit message to collect Advertise messages, unless it receives an Advertise message with a preference value of 255. The preference value is carried in the Preference option (section 19.5). Any Solicit that does not include a Preference option is considered to have a preference value of 0. If the client receives an Advertise message with a preference value of 255, then the client MAY act immediately on that Advertise message without waiting for any more additional Advertise messages. Upon receipt of one or more validated Advertise messages, the client selects one or more Advertise messages based upon the following criteria. - Those Advertise messages with the highest server preference value are preferred over all other Advertise messages. - Within a group of Advertise messages with the same server preference value, a client MAY select those servers whose Advertise messages advertise information of interest to the client. For example, the client may choose a server that returned an advertisement with configuration options of interest to the client. Once a client has selected Advertise message(s), the client will typically store information about each server, such as server preference value, addresses advertised, when the advertisement was received, and so on. Depending on the requirements of the client's invoking user, the client MAY initiate a configuration exchange with the server(s) immediately, or MAY defer this exchange until later. If the client needs to select an alternate server in the case that a chosen server does not respond, the client chooses the server with the next highest preference value. The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available addresses advertised in IAs. [...] 15. DHCP Client-Initiated Configuration Exchange [...] 15.3. Client Behavior [...] 15.3.1. Creation and transmission of Request messages If the client is using stateful address configuration and needs either an initial set of addresses or additional addresses, it MUST send a Request message to obtain new addresses and other configuration information. The client includes one or more IAs in the Request message, to which the server assigns new addresses. The server then returns IA(s) to the client in a Reply message. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client places the address of the destination server in the "server-address" field. The client adds a DUID option to identify itself to the server. The client adds any other appropriate options, including one or more IA options (if the client is requesting that the server assign it some network addresses). The list of addresses in each included IA MUST be empty. If the client is not requesting that the server assign it any addresses, the client omits the IA option. The client sends the Request message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REQ_MAX_ATTEMPTS MRT REP_MAX_RT MRD 0 If the message exchange fails, the client MAY choose one of the following actions: - Select another server from a list of servers known to the client; e. g., servers that responded with an Advertise message - Initiate the server discovery described in section 14 - Terminate the configuration process and report failure 15.3.2. Creation and transmission of Confirm messages Whenever a client may have moved to a new link, its IPv6 addresses and other configuration information may no longer be valid. Examples of times when a client may have moved to a new link include: o The client reboots o The client is physically disconnected from a wired connection o The client returns from sleep mode o The client using a wireless technology changes cells In any situation when a client may have moved to a new link, the client MUST initiate a Confirm/Reply message exchange. The client includes any IAs, along with the addresses associated with those IAs, in its Confirm message. Any responding servers will indicate the acceptability of the addresses with the status in the IA it returns to the client. The client sets the "msg-type" field to CONFIRM. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client sets the "server-address" field to 0. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options (if the client is requesting that the server confirm the validity of some network addresses). If the client does include any IA options, it MUST include the list of addresses the client currently has associated with that IA. The client sends the Confirm message to the All DHCP Agents multicast address through the interface for which the client is interested in confirming configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REQ_MSG_ATTEMPTS MRT REP_MAX_RT MRD 0 If the message exchange fails, the client MUST restart the configuration process by locating a DHCP server as described in section 14. The client SHOULD report the failure of the configuration process to the application layer. 15.3.3. Creation and transmission of Renew messages IPv6 addresses assigned to a client through an IA use the same preferred and valid lifetimes as IPv6 addresses obtained through stateless autoconfiguration. The server assigns preferred and valid lifetimes to the IPv6 addresses it assigns to an IA. To extend those lifetimes, the client sends a Request to the server containing an "IA option" for the IA and its associated addresses. The server determines new lifetimes for the addresses in the IA according to the server's administrative configuration. The server may also add new addresses to the IA. The server may remove addresses from the IA by setting the preferred and valid lifetimes of those addresses to zero. The server controls the time at which the client contacts the server to extend the lifetimes on assigned addresses through the T1 and T2 parameters assigned to an IA. If the server does not assign an explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the shortest preferred lifetime of any address assigned to the IA and T2 defaults to 0.875 times the shortest preferred lifetime of any address assigned to the IA. At time T1 for an IA, the client initiates a Request/Reply message exchange to extend the lifetimes on any addresses in the IA. The client includes an IA option with all addresses currently assigned to the IA in its Request message. The client sets the "msg-type" field to RENEW. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client places the address of the destination server in the "server-address" field. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options (if the client is requesting that the server extend the lease on some IAs; note that the client may check the status of other configuration parameters without asking for lease extensions). If the client does include any IA options, it MUST include the list of addresses the client currently has associated with that IA. The client sends the Renew message to the All DHCP Agents multicast address through the interface for which the client is interested in extending configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC 0 MRT REP_MAX_RT MRD 0 The mechanism in section 13 is modified as follows for use in the transmission of Renew messages. The message exchange is terminated when time T2 is reached (see section 15.3.4), at which time the client begins a Rebind message exchange. 15.3.4. Creation and transmission of Rebind messages At time T2 for an IA (which will only be reached if the server to which the Renew message was sent at time T1 has not responded), the client initiates a Rebind/Reply message exchange. The client includes an IA option with all addresses currently assigned to the IA in its Rebind message. The client sends this message to the All DHCP Agents multicast address. The client sets the "msg-type" field to REBIND. The client generates a transaction ID inserts this value in the "transaction-ID" field. The client sets the "server-address" field to 0. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options. If the client does include any IA options (if the client is requesting that the server extend the lease on some IAs; note that the client may check the status of other configuration parameters without asking for lease extensions), it MUST include the list of addresses the client currently has associated with that IA. The client sends the Rebind message to the All DHCP Agents multicast address through the interface for which the client is interested in extending configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC 0 MRT REP_MAX_RT MRD 0 The mechanism in section 13 is modified as follows for use in the transmission of Renew messages. The message exchange is terminated when the lease for the IA expires (see section 11), at which time the client has several alternative actions to choose from: - When the lease on the IA expires, the client may choose to use a Solicit message to locate a new DHCP server and send a Request for the expired IA to the new server - Some addresses in the IA may have lifetimes that extend beyond the lease of the IA, so the client may choose to continue to use those addresses; once all of the addresses have expired, the client may choose to locate a new DHCP server - The client may have other addresses in other IAs, so the client may choose to discard the expired IA and use the addresses in the other IAs 15.3.5. Receipt of Reply message in response to a Request, Confirm, Renew or Rebind message [...] 15.3.6. Creation and transmission of Release messages The client sets the "msg-type" field to RELEASE. The client generates a transaction ID and places this value in the "transaction-ID" field. The client places the IP address of the server that allocated the address(es) in the "server-address" field. The client adds a DUID option to identify itself to the server. The client includes options containing the IAs it is releasing in the "options" field. The addresses to be released MUST be included in the IAs. The appropriate "status" field in the options MUST be set to indicate the reason for the release. The client sends the Release message to the All DHCP Agents multicast address through the interface for which the client is interested in releasing configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. A client MAY choose to wait for a Reply message from the server in response to the Release message. If the client does wait for a Reply, the client MAY choose to retransmit the Release message. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REL_MSG_ATTEMPTS MRT REP_MAX_RT MRD 0 The client MUST abandon the attempt to release addresses if the Release message exchange fails. The client MUST stop using all of the addresses in the IA(s) being released as soon as the client begins the Release message exchange process. If an IA is released but the Reply from a DHCP server is lost, the client will retransmit the Release message, and the server may respond with a Reply indicating a status of "Nobinding". Therefore, the client must not treat a Reply message with a status of "Nobinding" in a Release message exchange as if it indicates an error. Note that if the client fails to release the IA, the addresses assigned to the IA will be reclaimed by the server when the lease associated with it expires. 15.3.7. Receipt of Reply message in response to a Release message Upon receipt of a valid Reply message, the client can consider the Release event successful, and SHOULD return the successful status to the application layer, if an application initiated the release. 15.3.8. Creation and transmission of Decline messages The client sets the "msg-type" field to DECLINE. The client generates a transaction ID and places this value in the "transaction-ID" field. The client places the IP address of the server that allocated the address(es) in the "server-address" field. The client adds a DUID option to identify itself to the server. The client includes options containing the IAs it is declining in the "options" field. The addresses to be released MUST be included in the IAs. The appropriate "status" field in the options MUST be set to indicate the reason for declining the address. The client sends the Decline message to the All DHCP Agents multicast address through the interface for which the client is interested in declining addresses, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REL_ATTEMPTS MRT REP_MAX_RT MRD 0 The client MUST abandon the attempt to decline addresses if the Decline message exchange fails. 15.3.9. Receipt of Reply message in response to a Decline message Upon receipt of a valid Reply message, the client can consider the Decline event successful. [...] _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 4 22:45:50 2001 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 WAA04513; Tue, 4 Sep 2001 22:45:50 -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 WAA15957; Tue, 4 Sep 2001 22:42:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15931 for ; Tue, 4 Sep 2001 22:42:23 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04457 for ; Tue, 4 Sep 2001 22:40:56 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-43.cisco.com [10.82.224.43]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA10457 for ; Tue, 4 Sep 2001 22:41:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20010904223858.041b0ed0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Sep 2001 22:41:43 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] DHCPv6 spec text for retransmission In-Reply-To: <4.3.2.7.2.20010904214019.00b7fad0@funnel.cisco.com> 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: X-BeenThere: dhcwg@ietf.org Now that I think about it, PDP 8 assembler code is probably what I was writing in my youth... - Ralph At 09:49 PM 9/4/2001 -0400, Ralph Droms wrote: >..Perhaps I misspent > too much of my youth writing 8080 assembler > code and it's just not important to worry about > setting those limits around powers of two. If > +-0.1 makes more sense, that's fine with me. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 5 10:12:02 2001 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 KAA03230; Wed, 5 Sep 2001 10:11:58 -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 KAA09799; Wed, 5 Sep 2001 10:09:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09767 for ; Wed, 5 Sep 2001 10:09:21 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02904 for ; Wed, 5 Sep 2001 10:07:55 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp140-94.cisco.com [161.44.140.94]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA18325 for ; Wed, 5 Sep 2001 10:08:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20010905100656.00b8ea50@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Sep 2001 10:08:33 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] client unicast/client unicast option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Here's the text that has been changed to allow for client unicast, controlled by the client unicast option. Please review and comment... - Ralph ===== 15.3.1. Creation and transmission of Request messages If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Request message to the server. Otherwise, the client sends the Request message to the All_DHCP_Agents multicast address. The client sends the Request message through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. 15.3.3. Creation and transmission of Renew messages If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Renew message to the server. Otherwise, the client sends the Renew message to the All_DHCP_Agents multicast address. The client sends the Renew message through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. 15.3.6. Creation and transmission of Release messages If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Release message to the server. Otherwise, the client sends the Release message to the All_DHCP_Agents multicast address. The client sends the Release message through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. 15.3.8. Creation and transmission of Decline messages If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Decline message to the server. Otherwise, the client sends the Decline message to the All_DHCP_Agents multicast address. The client sends the Decline message through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. 19.12. Server unicast option This option is used by a server to send to a client to inform the client it can send a Request, Renew, Release, and Decline by unicasting directly to the server instead of the All_DHCPv6_Agents Multicast address as an optimization, when the client as an address of sufficient scope to reach the server. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_UNICAST | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_UNICAST (9) option-length 0 This option only applies to the server address that sends this to the client. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 5 10:55:15 2001 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 KAA05939; Wed, 5 Sep 2001 10:55:15 -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 KAA11741; Wed, 5 Sep 2001 10:51:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11714 for ; Wed, 5 Sep 2001 10:51:43 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05625 for ; Wed, 5 Sep 2001 10:50:16 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f85EpC527782 for ; Wed, 5 Sep 2001 09:51:12 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f85EpC321322 for ; Wed, 5 Sep 2001 09:51:12 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Sep 05 09:51:11 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Sep 2001 09:51:11 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B352F@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] client unicast/client unicast option Date: Wed, 5 Sep 2001 09:51:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1361A.306C5460" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1361A.306C5460 Content-Type: text/plain; charset="iso-8859-1" In general, looks fine to me. Don't know if it is worth adding a line into the Release/Decline text to specifically indicate that a client can obviously not use one of the addresses it is Releasing or Declining (that is obvious isn't it). The one other minor comment is whether a client *MUST* send unicast packets out the interface for which the client is obtaining configuration information? As long as the client's SOURCE address is set correctly to reflect the proper interface, there really is no problem in it sending the packet out whatever interface the routing table indicates, is there? In the multicast case (or if the SOURCE address is a link scoped address), it is important since the client must use its link local address (and that is only valid on that interface). I'm probably being too nit picky! - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, September 05, 2001 10:09 AM To: dhcwg@ietf.org Subject: [dhcwg] client unicast/client unicast option Here's the text that has been changed to allow for client unicast, controlled by the client unicast option. Please review and comment... - Ralph ===== 15.3.1. Creation and transmission of Request messages If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Request message to the server. Otherwise, the client sends the Request message to the All_DHCP_Agents multicast address. The client sends the Request message through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. 15.3.3. Creation and transmission of Renew messages If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Renew message to the server. Otherwise, the client sends the Renew message to the All_DHCP_Agents multicast address. The client sends the Renew message through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. 15.3.6. Creation and transmission of Release messages If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Release message to the server. Otherwise, the client sends the Release message to the All_DHCP_Agents multicast address. The client sends the Release message through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. 15.3.8. Creation and transmission of Decline messages If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Decline message to the server. Otherwise, the client sends the Decline message to the All_DHCP_Agents multicast address. The client sends the Decline message through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. 19.12. Server unicast option This option is used by a server to send to a client to inform the client it can send a Request, Renew, Release, and Decline by unicasting directly to the server instead of the All_DHCPv6_Agents Multicast address as an optimization, when the client as an address of sufficient scope to reach the server. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_UNICAST | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_UNICAST (9) option-length 0 This option only applies to the server address that sends this to the client. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1361A.306C5460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] client unicast/client unicast option

In general, looks fine to me.

Don't know if it is worth adding a line into the = Release/Decline text to specifically indicate that a client can = obviously not use one of the addresses it is Releasing or Declining = (that is obvious isn't it).

The one other minor comment is whether a client = *MUST* send unicast packets out the interface for which the client is = obtaining configuration information? As long as the client's SOURCE = address is set correctly to reflect the proper interface, there really = is no problem in it sending the packet out whatever interface the = routing table indicates, is there? In the multicast case (or if the = SOURCE address is a link scoped address), it is important since the = client must use its link local address (and that is only valid on that = interface).

I'm probably being too nit picky!

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, September 05, 2001 10:09 AM
To: dhcwg@ietf.org
Subject: [dhcwg] client unicast/client unicast = option


Here's the text that has been changed to allow for = client unicast, controlled by the client unicast option.

Please review and comment...

- Ralph

=3D=3D=3D=3D=3D

15.3.1. Creation and transmission of Request = messages

   If the client has a source address that = can be used by the server
   as a return address and the client has = received a Client Unicast
   option (section 19.12) from the server, = the client SHOULD unicast
   the Request message to the = server.  Otherwise, the client sends
   the Request message to the = All_DHCP_Agents multicast address.  The
   client sends the Request message = through the interface for which
   the client is interested in obtaining = configuration information,
   with the destination port set to = 547.  The source port selection
   can be arbitrary, although it SHOULD be = possible using a client
   configuration facility to set a = specific source port value.


15.3.3. Creation and transmission of Renew = messages

   If the client has a source address that = can be used by the server as
   a return address and the client has = received a Client Unicast option
   (section 19.12) from the server, the = client SHOULD unicast the Renew
   message to the server.  Otherwise, = the client sends the Renew message
   to the All_DHCP_Agents multicast = address.  The client sends the Renew
   message through the interface for which = the client is interested in
   obtaining configuration information, = with the destination port set
   to 547.  The source port selection = can be arbitrary, although it
   SHOULD be possible using a client = configuration facility to set a
   specific source port value.


15.3.6. Creation and transmission of Release = messages

   If the client has a source address that = can be used by the server
   as a return address and the client has = received a Client Unicast
   option (section 19.12) from the server, = the client SHOULD unicast
   the Release message to the = server.  Otherwise, the client sends
   the Release message to the = All_DHCP_Agents multicast address.  The
   client sends the Release message = through the interface for which
   the client is interested in obtaining = configuration information,
   with the destination port set to = 547.  The source port selection
   can be arbitrary, although it SHOULD be = possible using a client
   configuration facility to set a = specific source port value.


15.3.8. Creation and transmission of Decline = messages

   If the client has a source address that = can be used by the server
   as a return address and the client has = received a Client Unicast
   option (section 19.12) from the server, = the client SHOULD unicast
   the Decline message to the = server.  Otherwise, the client sends
   the Decline message to the = All_DHCP_Agents multicast address.  The
   client sends the Decline message = through the interface for which
   the client is interested in obtaining = configuration information,
   with the destination port set to = 547.  The source port selection
   can be arbitrary, although it SHOULD be = possible using a client
   configuration facility to set a = specific source port value.


19.12. Server unicast option

   This option is used by a server to send = to a client to inform
   the client it can send a Request, = Renew, Release, and Decline by
   unicasting directly to the server = instead of the All_DHCPv6_Agents
   Multicast address as an optimization, = when the client as an address
   of sufficient scope to reach the = server.

    = 0            = ;       = 1            = ;       = 2            = ;       3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   = |        = OPTION_UNICAST         = |        = option-length          = |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+


      = option-code     OPTION_UNICAST (9)

      = option-length   0

   This option only applies to the server = address that sends this to the
   client.



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

------_=_NextPart_001_01C1361A.306C5460-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 5 11:03:37 2001 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 LAA06467; Wed, 5 Sep 2001 11:03:37 -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 LAA12562; Wed, 5 Sep 2001 11:02:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12538 for ; Wed, 5 Sep 2001 11:02:51 -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 LAA06371 for ; Wed, 5 Sep 2001 11:01: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 f85F2kf27346; Wed, 5 Sep 2001 08:02:47 -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 f85F2Th00600; Wed, 5 Sep 2001 11:02:29 -0400 (EDT) Message-Id: <200109051502.f85F2Th00600@grosse.bisbee.fugue.com> To: "Bernie Volz (EUD)" cc: "'Ralph Droms'" , dhcwg@ietf.org Subject: Re: [dhcwg] client unicast/client unicast option In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 05 Sep 2001 09:51:05 CDT." <66F66129A77AD411B76200508B65AC697B352F@eambunt705.ena-east.ericsson.se> Date: Wed, 05 Sep 2001 11:02:29 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Don't know if it is worth adding a line into the Release/Decline > text to specifically indicate that a client can obviously not use > one of the addresses it is Releasing or Declining (that is obvious > isn't it). I think it's definitely worth adding text that makes this explicit. It really is not obvious. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 5 11:22:06 2001 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 LAA07307; Wed, 5 Sep 2001 11:22:06 -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 LAA13281; Wed, 5 Sep 2001 11:21:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13260 for ; Wed, 5 Sep 2001 11:20:59 -0400 (EDT) Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07134 for ; Wed, 5 Sep 2001 11:19:33 -0400 (EDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f85FIVi02279; Wed, 5 Sep 2001 11:18:31 -0400 Message-Id: <200109051518.f85FIVi02279@hygro.adsl.duke.edu> To: "Bernie Volz (EUD)" cc: dhcwg@ietf.org Subject: Re: [dhcwg] How to encode DNS labels in DHCP options In-Reply-To: Message from "Tue, 04 Sep 2001 15:38:18 CDT." <66F66129A77AD411B76200508B65AC697B351A@eambunt705.ena-east.ericsson.se> Date: Wed, 05 Sep 2001 11:18:31 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Bernie, > The problem is that the FQDN option is already in such wide > deployment with the ASCII encoding that it would be impossible to > ask that everyone change to using the new. Which clients implement this? I.e, if there are lots of clients sending this out to servers today, than the spec should document this so servers can respond appropriately (or at the very least, not choke). But it would be good to know the number of clients we are talking about. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 5 11:25:05 2001 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 LAA07475; Wed, 5 Sep 2001 11:25:00 -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 LAA13444; Wed, 5 Sep 2001 11:24:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13418 for ; Wed, 5 Sep 2001 11:24:31 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07357 for ; Wed, 5 Sep 2001 11:23:04 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f85FNv520288 for ; Wed, 5 Sep 2001 10:23:57 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f85FNv307597 for ; Wed, 5 Sep 2001 10:23:57 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Sep 05 10:23:56 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Sep 2001 10:23:56 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3534@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] How to encode DNS labels in DHCP options Date: Wed, 5 Sep 2001 10:23:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1361E.C3436FE0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1361E.C3436FE0 Content-Type: text/plain; charset="iso-8859-1" Well, how about many of the Microsoft clients? That is likely 10's or 100's of millions. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@raleigh.ibm.com] Sent: Wednesday, September 05, 2001 11:19 AM To: Bernie Volz (EUD) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] How to encode DNS labels in DHCP options Bernie, > The problem is that the FQDN option is already in such wide > deployment with the ASCII encoding that it would be impossible to > ask that everyone change to using the new. Which clients implement this? I.e, if there are lots of clients sending this out to servers today, than the spec should document this so servers can respond appropriately (or at the very least, not choke). But it would be good to know the number of clients we are talking about. Thomas ------_=_NextPart_001_01C1361E.C3436FE0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] How to encode DNS labels in DHCP options

Well, how about many of the Microsoft clients? That is likely 10's or 100's of millions.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@raleigh.ibm.com]
Sent: Wednesday, September 05, 2001 11:19 AM
To: Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] How to encode DNS labels in DHCP options


Bernie,

> The problem is that the FQDN option is already in such wide
> deployment with the ASCII encoding that it would be impossible to
> ask that everyone change to using the new.

Which clients implement this? I.e, if there are lots of clients
sending this out to servers today, than the spec should document this
so servers can respond appropriately (or at the very least, not
choke). But it would be good to know the number of clients we are
talking about.

Thomas

------_=_NextPart_001_01C1361E.C3436FE0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 5 13:52:23 2001 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 NAA12481; Wed, 5 Sep 2001 13:52:23 -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 NAA18236; Wed, 5 Sep 2001 13:49:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18213 for ; Wed, 5 Sep 2001 13:49:56 -0400 (EDT) Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12279 for ; Wed, 5 Sep 2001 13:48:29 -0400 (EDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f85HlTZ03658; Wed, 5 Sep 2001 13:47:29 -0400 Message-Id: <200109051747.f85HlTZ03658@hygro.adsl.duke.edu> To: Mark Stapp cc: dhcwg@ietf.org Subject: Re: [dhcwg] How to encode DNS labels in DHCP options In-Reply-To: Message from "Tue, 04 Sep 2001 17:27:19 EDT." <4.3.2.7.2.20010904170432.02ac0330@funnel.cisco.com> Date: Wed, 05 Sep 2001 13:47:28 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi Mark. > As Bernie noted, there's a historical problem in this case that makes it > unusually painful to remove text about the ASCII behavior entirely. We > don't want new clients to implement the deprecated behavior, but we need to > describe it for the benefit of new server implementations which will > encounter old clients for a long time to come. Makes sense to me. > This is the revised text from section 4.1, describing the use of the "E" flag: > The data in the Domain Name field SHOULD appear in DNS-style binary > encoding (without compression, of course), as described in > RFC1035[3]. A client which sends the FQDN option SHOULD use this > encoding. The client MUST set the "E" bit when the data in the > Domain Name field is in DNS binary encoding. If a server receives an > FQDN option from a client, and intends to include an FQDN option in > its reply, it MUST use the same encoding that the client used, and > MUST set the "E" bit accordingly. My only quibble with the above is the SHOULD. Why not a MUST? If you want clients that implement *this* spec to implement the binary encoding, seems like it should be a MUST (i.e., no wiggle room). Saying SHOULD allows them to implement the ascii flavor and be compliant. That wouldn't seem to be the goal here. > 4.3 The Domain Name Field > The Domain Name part of the option carries all or part of the FQDN > of a DHCP client. The data in the Domain Name field SHOULD appear in > uncompressed DNS encoding as specified in RFC1035[3]. If the DHCP > client uses DNS encoding, it MUST set the third bit in the Flags > field (the "E" bit). A client may be configured with a > fully-qualified domain name, or with a partial name that is not > fully-qualified. If a client knows only part of its name, it MAY > send a name that is not fully-qualified, indicating that it knows > part of the name but does not necessarily know the zone in which the > name is to be embedded. Might be good to say that "not fully-qualified" really means a single label. > Does this help? Is this too much change, or the right amount? Is there > anything that's still unclear after these changes? Overall, this seems much better to me. Thanks, Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 6 05:22:11 2001 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 FAA18334; Thu, 6 Sep 2001 05:22:11 -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 FAA17241; Thu, 6 Sep 2001 05:21:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17214 for ; Thu, 6 Sep 2001 05:21:22 -0400 (EDT) Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18276 for ; Thu, 6 Sep 2001 05:19:51 -0400 (EDT) Received: from there ([193.12.201.10]) by fep04-svc.swip.net with SMTP id <20010906092043.IUA16067.fep04-svc.swip.net@there> for ; Thu, 6 Sep 2001 11:20:43 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Subject: Re: [dhcwg] How to encode DNS labels in DHCP options Date: Thu, 6 Sep 2001 11:23:46 +0200 X-Mailer: KMail [version 1.3] References: <200108280112.f7S1C6T00354@grosse.bisbee.fugue.com> <4.3.2.7.2.20010904170432.02ac0330@funnel.cisco.com> In-Reply-To: <4.3.2.7.2.20010904170432.02ac0330@funnel.cisco.com> MIME-Version: 1.0 Message-Id: <20010906092043.IUA16067.fep04-svc.swip.net@there> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA17215 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit I'll admit I don't know much about the DNS binary name format, but I'm going to ask: why is it better to encode DNS names in binary than ASCII? -- Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 70 566 7803 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 6 10:01:14 2001 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 KAA27682; Thu, 6 Sep 2001 10:01:14 -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 JAA23145; Thu, 6 Sep 2001 09:58:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23118 for ; Thu, 6 Sep 2001 09:58:23 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27548 for ; Thu, 6 Sep 2001 09:56:56 -0400 (EDT) Received: from cisco.com (dhcp-161-44-148-129.cisco.com [161.44.148.129]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA17118; Thu, 6 Sep 2001 09:57:44 -0400 (EDT) Message-ID: <3B97809F.ADF3F8F0@cisco.com> Date: Thu, 06 Sep 2001 09:56:47 -0400 From: Josh Littlefield Organization: Cisco Systems X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bud Millwood CC: dhcwg@ietf.org Subject: Re: [dhcwg] How to encode DNS labels in DHCP options References: <200108280112.f7S1C6T00354@grosse.bisbee.fugue.com> <4.3.2.7.2.20010904170432.02ac0330@funnel.cisco.com> <20010906092043.IUA16067.fep04-svc.swip.net@there> 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: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Bud Millwood wrote: > > I'll admit I don't know much about the DNS binary name format, but I'm going > to ask: why is it better to encode DNS names in binary than ASCII? There are no special characters (such as ".", or a null terminator) in DNS native format, so it requires no quoting characters (which would themselves require quoting). It is not intended to be directly printable, so character set issues are transparent, or will be when IDN resolves questions about localized, non-7-bit ASCII names. The form is simply a series of counted label strings, so no real parsing is involved in handling the names. -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 6 12:50:10 2001 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 MAA02386; Thu, 6 Sep 2001 12:50:10 -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 MAA27877; Thu, 6 Sep 2001 12:45:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27851 for ; Thu, 6 Sep 2001 12:45:18 -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 MAA02228 for ; Thu, 6 Sep 2001 12:43:52 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-228.ip.theriver.com [205.140.116.228]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f86Gj3f29539; Thu, 6 Sep 2001 09:45:03 -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 f86Gimq00382; Thu, 6 Sep 2001 09:44:48 -0700 (MST) Message-Id: <200109061644.f86Gimq00382@grosse.bisbee.fugue.com> To: Bud Millwood cc: dhcwg@ietf.org Subject: Re: [dhcwg] How to encode DNS labels in DHCP options In-Reply-To: Message from Bud Millwood of "Thu, 06 Sep 2001 11:23:46 +0200." <20010906092043.IUA16067.fep04-svc.swip.net@there> Date: Thu, 06 Sep 2001 09:44:48 -0700 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > I'll admit I don't know much about the DNS binary name format, but I'm going > to ask: why is it better to encode DNS names in binary than ASCII? The short answer to this is that you shouldn't ask questions like this on a working group mailing list - you should learn about the format. However, in this case reading RFC1035 probably wouldn't answer your question. The answer is that the RFC1035 format is at least theoretically capable of handling unicode, whereas an ASCII representation obviously is not. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 6 13:31:32 2001 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 NAA03467; Thu, 6 Sep 2001 13:31: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 NAA29006; Thu, 6 Sep 2001 13:30:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28968 for ; Thu, 6 Sep 2001 13:30:44 -0400 (EDT) Received: from sni19.hitel.net ([203.245.15.198]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03415 for ; Thu, 6 Sep 2001 13:29:16 -0400 (EDT) From: unixos@hitel.net Received: from UNIXOS ([61.79.239.220]) by sni19.hitel.net (Netscape Messaging Server 4.15) with SMTP id GJ94N302.564; Fri, 7 Sep 2001 02:30:39 +0900 Message-ID: <002701c136fa$0d046400$0200000a@yuritech> To: "Ted Lemon" Cc: References: <200109061644.f86Gimq00382@grosse.bisbee.fugue.com> Subject: Re: [dhcwg] How to encode DNS labels in DHCP options ==> IDN Issue Date: Fri, 7 Sep 2001 02:33:32 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi! It's My Comment.... ----- Original Message ----- From: "Ted Lemon" To: "Bud Millwood" Cc: Sent: Friday, September 07, 2001 1:44 AM Subject: Re: [dhcwg] How to encode DNS labels in DHCP options > > > I'll admit I don't know much about the DNS binary name format, but I'm going > > to ask: why is it better to encode DNS names in binary than ASCII? > > The short answer to this is that you shouldn't ask questions like this > on a working group mailing list - you should learn about the format. > However, in this case reading RFC1035 probably wouldn't answer your > question. The answer is that the RFC1035 format is at least > theoretically capable of handling unicode, whereas an ASCII > representation obviously is not. > > _MelloN_ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > It is IDN WG Issue. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 6 20:59:29 2001 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 UAA13042; Thu, 6 Sep 2001 20:59:28 -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 UAA12609; Thu, 6 Sep 2001 20:57:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07421 for ; Thu, 6 Sep 2001 18:25:09 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10245 for ; Thu, 6 Sep 2001 18:23:41 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f86MOc518839 for ; Thu, 6 Sep 2001 17:24:38 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f86MOcq29144 for ; Thu, 6 Sep 2001 17:24:38 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu Sep 06 17:24:37 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 17:24:37 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B354D@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] DHCPv6 spec text for retransmission Date: Thu, 6 Sep 2001 17:24:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13722.B5E8E780" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13722.B5E8E780 Content-Type: text/plain; charset="iso-8859-1" Ralph: See my comments inline below (prefixed by BV>). Please do look at my comments in 15.3.4 (also applies to Renew). We have a protocol problem we likely need to correct! -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, September 04, 2001 9:49 PM To: dhcwg@ietf.org Subject: [dhcwg] DHCPv6 spec text for retransmission Here is the new text in the DHCPv6 spec describing the transmission and retransmission mechanism for client messages. Thanks to Ted for writing the first draft of this text. Notes: * I chose +-0.0625 (2^-4) as the limits on the randomization factor to (potentially) make the arithmetic a little easier. Perhaps I misspent too much of my youth writing 8080 assembler code and it's just not important to worry about setting those limits around powers of two. If +-0.1 makes more sense, that's fine with me. BV> I'd go with +/- 0.1 because almost all systems can do BV> floating point math these days and you likely need to BV> anyway. If a system can't, it can always fall back to BV> a "close" approximatation (such as +/- 0.0625). * I did not choose to base the server Reconfigure-init retransmission mechanism on section 13. I don't think the DHCPv6 spec needs to dictate the behavior of the server when retransmitting Reconfigure-init messages. * There are some references to the use of IAs; the new IA text has not been finalized and does not yet appear in the doc. Please review this new text and reply with comments... - Ralph 7.5. Configuration Variables This section presents a table of client and server configuration variables and the default or initial values for these variables. The client-specific variables MAY be configured on the server and MAY be delivered to the client through the "DHCP Retransmission Parameter Option" in a Reply message. BV> Didn't we want to drop this retransmission parameter option BV> since it opens up many cans of worms as per the San Diego IETF? Parameter Default Description ------------------------------------- MIN_SOL_DELAY 1 MIN (secs) to delay 1st mesg MAX_SOL_DELAY 5 MAX (secs) to delay 1st mesg ADV_TIMEOUT 500 SOL Retrans timer (msecs) ADV_MAX_RT 30 MAX timer value (secs) SOL_MAX_ATTEMPTS 0 MAX attempts (0 = infinite) REP_TIMEOUT 250 Retrans timer (msecs) for Reply REP_MAX_RT 0 MAX Retrans time (0 = infinite) REQ_MAX_ATTEMPTS 10 MAX Request/Confirm/Renew/Rebind attempts REL_MSG_ATTEMPTS 5 MAX Release/Decline attempts SRVR_PREF_WAIT 2 Advertise Collect timer (secs) 13. Reliability of Client Initiated Message Exchanges DHCP clients are responsible for reliable delivery of messages in the client-initiated message exchanges described in sections 14 and 15. If a DHCP client fails to receive an expected response from a server, the client must retransmit its message. This section describes the retransmission strategy to be used by clients in client-initiated message exchanges. The client begins the message exchange by transmitting a message to the server. The message exchange terminates when either the client successfully receives the appropriate response or responses from a server or servers, or when the message exchange is considered to have failed according to the retransmission mechanism described below. The client retransmission behavior is controlled and describe by five variables: RT Retransmission timeout IRT Initial retransmission time MRC Maximum retransmission count MRT Maximum retransmission time MRD Maximum retransmission duration RAND Randomization factor With each message transmission or retransmission, the client sets RT according to the rules given below. If RT expires before the message exchange terminates, the client recomputes RT and retransmits the message. Each of the computations of a new RT include a randomization factor (RAND), which is a random number chosen with a uniform distribution between -0.0625 and +0.0625. The randomization factor is included to minimize synchronization of messages transmitted by DHCP clients. The algorithm for choosing a random number does not need to be cryptographically sound. The algorithm SHOULD produce a different sequence of numbers from each invocation of the DHCP client. RT for the first message transmission is based on IRT: RT = IRT + RAND*IRT RT for each subsequent message transmission is based on the previous value of RT: RT = RTprev + RAND*RTprev MRT specifies an upper bound on the value of RT. If MRT has a value of 0, there is no upper limit on the value of RT. Otherwise: if (RT > MRT) RT = MRT + RAND*MRT MRC specifies an upper bound on the number of times a client may retransmit a message. If MRC has a value of 0, the client MUST continue to retransmit the original message until a response is received. Otherwise, the message exchange fails if the client attempts to transmit the original message more than MRC times. MRD specifies an upper bound on the length of time a client may retransmit a message. If MRD has a value of 0, the client MUST continue to retransmit the original message until a response is received. Otherwise, the message exchange fails if the client attempts to transmit the original message more than MRD seconds. BV> Just to be clear, might be good to say that EITHER or BOTH of BV> MRC or MRD can stop retransmissions? In most cases it appears BV> that only one is active, but it is always possible that both BV> could be. 14. DHCP Server Solicitation This section describes how a client locates servers. The behavior of client and server implementations is discussed, along with the messages they use. [...] 14.3. Client Behavior A client uses the Solicit message to discover DHCP servers configured to serve addresses on the link to which the client is attached. 14.3.1. Creation of Solicit messages The client sets the "msg-type" field to SOLICIT. The client generates a transaction ID and inserts this value in the "transaction-ID" field. BV> While probably not something that is needed in this section, we BV> really don't have much text to describe the "transaction-ID". All BV> we generally say is to "generate a transaction ID". However, we BV> should make it clear to clients that they should attempt to BV> generate "unique" transaction ids. Unique here is best if it is BV> over a long period of time, but it must be longer than any cache BV> times in servers. Probably the best rule of thumb is for clients BV> to use to generate this number by incrementing it. Then the only BV> issue is what to set it to when (re)booting - especially if there BV> is no means to remember the last used number. The client includes a DUID option to identify itself to the server. The client MUST include options for any IAs to which it wants the server to assign addresses. The client may include addresses in the IAs as a hint to the server about addresses for which the client may have a preference. The client MAY include an Option Request Option in the Solicit message. The client MUST NOT include any other options except those specifically allowed as defined by specific options. 14.3.2. Transmission of Solicit Messages The client sends the Solicit message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client's first Solicit message on the interface MUST be delayed by a random amount of time between MIN_SOL_DELAY and MAX_SOL_DELAY. This random delay desynchronizes clients which start at the same time (e.g., after a power outage). The client transmits the message according to section 13, using the following parameters: IRT ADV_TIMEOUT MRC SOL_MAX_ATTEMPTS MRT ADV_MAX_RT MRD 0 The mechanism in section 13 is modified as follows for use in the transmission of Solicit messages. The message exchange is not terminated by the receipt of an Advertise before ADV_MSG_TIMEOUT BV> ADV_MSG_TIMEOUT doesn't exist. I think you renamed it to BV> ADV_TIMEOUT? ADV_MSG_TIMEOUT is used many times. has elapsed. Rather, the client collects Advertise messages until ADV_MSG_TIMEOUT has elapsed. The first RT MUST be selected to be strictly greater than ADV_MSG_TIMEOUT by choosing RAND to be strictly greater than 0. A DHCP client SHOULD choose MRC and MRT to be 0. If the DHCP client is otherwise configured, it MUST stop trying to configure the interface if the message exchange fails. After the DHCP client stops trying to configure the interface, it MAY choose to restart the reconfiguration process after some external event, such as user input, system restart, or when the client is attached to a new link. BV> Did you mean MRD, not MRT? MRT limits the time of a single BV> retransmission. Also, the "If the DHCP client is otherwise configured" BV> made me re-read the paragraph several times. Perhaps there is a better BV> way to state this? "If the DHCP client is configured with a non-zero BV> MRC or MRD, ...". BV> Oh, might you want to say "SOL_MAX_ATTEMPTS" instead of MRC? BV> Also, this Retransmit logic is a bit weird beause of SRVR_PREF_WAIT. BV> Does it make sense to state something like "A client only retransmits BV> a Solicit if it fails to receive any Advertises before the retransmission BV> timer expires. If a client receives one or more Advertise messages, it BV> then must wait SRVR_PERF_WAIT seconds from the time of the transmit BV> for any additional Advertise messages before proceeding." 14.3.3. Receipt of Advertise messages A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP Solicit message to collect Advertise messages, unless it receives an Advertise message with a preference value of 255. The preference value is carried in the Preference option (section 19.5). Any Solicit that does not include a Preference option is considered to have a preference value of 0. If the client receives an Advertise message with a preference value of 255, then the client MAY act immediately on that Advertise message without waiting for any more additional Advertise messages. Upon receipt of one or more validated Advertise messages, the client selects one or more Advertise messages based upon the following criteria. - Those Advertise messages with the highest server preference value are preferred over all other Advertise messages. - Within a group of Advertise messages with the same server preference value, a client MAY select those servers whose Advertise messages advertise information of interest to the client. For example, the client may choose a server that returned an advertisement with configuration options of interest to the client. Once a client has selected Advertise message(s), the client will typically store information about each server, such as server preference value, addresses advertised, when the advertisement was received, and so on. Depending on the requirements of the client's invoking user, the client MAY initiate a configuration exchange with the server(s) immediately, or MAY defer this exchange until later. If the client needs to select an alternate server in the case that a chosen server does not respond, the client chooses the server with the next highest preference value. The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available addresses advertised in IAs. [...] 15. DHCP Client-Initiated Configuration Exchange [...] 15.3. Client Behavior [...] 15.3.1. Creation and transmission of Request messages If the client is using stateful address configuration and needs either an initial set of addresses or additional addresses, it MUST send a Request message to obtain new addresses and other configuration information. The client includes one or more IAs in the Request message, to which the server assigns new addresses. The server then returns IA(s) to the client in a Reply message. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client places the address of the destination server in the "server-address" field. The client adds a DUID option to identify itself to the server. The client adds any other appropriate options, including one or more IA options (if the client is requesting that the server assign it some network addresses). The list of addresses in each included IA MUST be empty. If the client is not requesting that the server assign it any addresses, the client omits the IA option. The client sends the Request message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REQ_MAX_ATTEMPTS MRT REP_MAX_RT MRD 0 If the message exchange fails, the client MAY choose one of the following actions: - Select another server from a list of servers known to the client; e. g., servers that responded with an Advertise message - Initiate the server discovery described in section 14 - Terminate the configuration process and report failure 15.3.2. Creation and transmission of Confirm messages Whenever a client may have moved to a new link, its IPv6 addresses and other configuration information may no longer be valid. Examples of times when a client may have moved to a new link include: o The client reboots o The client is physically disconnected from a wired connection o The client returns from sleep mode o The client using a wireless technology changes cells In any situation when a client may have moved to a new link, the client MUST initiate a Confirm/Reply message exchange. The client includes any IAs, along with the addresses associated with those IAs, in its Confirm message. Any responding servers will indicate the acceptability of the addresses with the status in the IA it returns to the client. The client sets the "msg-type" field to CONFIRM. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client sets the "server-address" field to 0. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options (if the client is requesting that the server confirm the validity of some network addresses). If the client does include any IA options, it MUST include the list of addresses the client currently has associated with that IA. The client sends the Confirm message to the All DHCP Agents multicast address through the interface for which the client is interested in confirming configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REQ_MSG_ATTEMPTS MRT REP_MAX_RT MRD 0 If the message exchange fails, the client MUST restart the configuration process by locating a DHCP server as described in section 14. The client SHOULD report the failure of the configuration process to the application layer. 15.3.3. Creation and transmission of Renew messages IPv6 addresses assigned to a client through an IA use the same preferred and valid lifetimes as IPv6 addresses obtained through stateless autoconfiguration. The server assigns preferred and valid lifetimes to the IPv6 addresses it assigns to an IA. To extend those lifetimes, the client sends a Request to the server containing an BV> Renew! "IA option" for the IA and its associated addresses. The server determines new lifetimes for the addresses in the IA according to the server's administrative configuration. The server may also add new addresses to the IA. The server may remove addresses from the IA by setting the preferred and valid lifetimes of those addresses to zero. The server controls the time at which the client contacts the server to extend the lifetimes on assigned addresses through the T1 and T2 parameters assigned to an IA. If the server does not assign an explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the shortest preferred lifetime of any address assigned to the IA and T2 defaults to 0.875 times the shortest preferred lifetime of any address assigned to the IA. BV> Perhaps this is "not in this set of edits", but I think we did BV> decide to always have the server send T1/T2 times. Therefore, BV> there should be no need to have "defaults". At time T1 for an IA, the client initiates a Request/Reply message exchange to extend the lifetimes on any addresses in the IA. The client includes an IA option with all addresses currently assigned to the IA in its Request message. The client sets the "msg-type" field to RENEW. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client places the address of the destination server in the "server-address" field. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options (if the client is requesting that the server extend the lease on some IAs; note that the client may check the status of other configuration parameters without asking for lease extensions). If the client does include any IA options, it MUST include the list of addresses the client currently has associated with that IA. The client sends the Renew message to the All DHCP Agents multicast address through the interface for which the client is interested in extending configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC 0 MRT REP_MAX_RT MRD 0 The mechanism in section 13 is modified as follows for use in the transmission of Renew messages. The message exchange is terminated when time T2 is reached (see section 15.3.4), at which time the client begins a Rebind message exchange. BV> One can also set MRD = T2-T1. The only issue there is that the BV> recovery step from the timeout is to start a REBIND. It should BV> be noted that the REBIND is a new message and not a retransmission BV> and therefore a new transaction ID must be chosen. 15.3.4. Creation and transmission of Rebind messages At time T2 for an IA (which will only be reached if the server to which the Renew message was sent at time T1 has not responded), the client initiates a Rebind/Reply message exchange. The client includes an IA option with all addresses currently assigned to the IA in its Rebind message. The client sends this message to the All DHCP Agents multicast address. The client sets the "msg-type" field to REBIND. The client generates a transaction ID inserts this value in the "transaction-ID" field. The client sets the "server-address" field to 0. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options. If the client does include any IA options (if the client is requesting that the server extend the lease on some IAs; note that the client may check the status of other configuration parameters without asking for lease extensions), it MUST include the list of addresses the client currently has associated with that IA. The client sends the Rebind message to the All DHCP Agents multicast address through the interface for which the client is interested in extending configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC 0 MRT REP_MAX_RT MRD 0 The mechanism in section 13 is modified as follows for use in the transmission of Renew messages. The message exchange is terminated when the lease for the IA expires (see section 11), at which time the client has several alternative actions to choose from: BV> Hum. This has some interesting problems (I don't know what Section BV> 11 refers to at this time, but don't recall the -19 draft having BV> much text in this area). The reason for the interesting problems BV> is because of the lifetime issue vs the T2 and renewal time. BV> What happens if an IA has two addresses. One has a valid lifetime BV> of 2 weeks. The other has a valid lifetime of 3 days. The T2 time BV> is 2 days. So, suppose the servers are non-responsive for 4 days. BV> When does the client stop retransmitting the message? When does it BV> alter it to remove the address with the expired lifetime (after 3 BV> days). Does this change to the message mean it MUST change the BV> XID? BV> I would suggest we say that MRD is shortest-valid-lifetime - T2. BV> Once that retransmission expires, the client must generate a BV> new Rebind message if there are *ANY* addresses still valid. It BV> stops only after all addresses are no longer valid. BV> We should also fix all the terminology such as "when the lease BV> on the IA expires"? It is really the valid lifetimes on the BV> individual addresses. BV> NOTE: The above issue for Rebind is *ALSO* a problem for Renew! BV> What if you had a third address with a 1 day valid lifetime BV> and T1 was 12 hours. 12 hours into the renew this third address BV> is gone and should be removed from the Renew. Hence, new message! BV> Hence, new transaction ID. Messy, messy, messy! - When the lease on the IA expires, the client may choose to use a Solicit message to locate a new DHCP server and send a Request for the expired IA to the new server - Some addresses in the IA may have lifetimes that extend beyond the lease of the IA, so the client may choose to continue to use those addresses; once all of the addresses have expired, the client may choose to locate a new DHCP server BV> Huh? How is this possible? There is no "lease" to an IA. An IA BV> dies when all of the addresses in that IA are no longer valid. There BV> is no other time that an IA dies. There is no "expire" time. - The client may have other addresses in other IAs, so the client may choose to discard the expired IA and use the addresses in the other IAs 15.3.5. Receipt of Reply message in response to a Request, Confirm, Renew or Rebind message [...] 15.3.6. Creation and transmission of Release messages The client sets the "msg-type" field to RELEASE. The client generates a transaction ID and places this value in the "transaction-ID" field. The client places the IP address of the server that allocated the address(es) in the "server-address" field. The client adds a DUID option to identify itself to the server. The client includes options containing the IAs it is releasing in the "options" field. The addresses to be released MUST be included in the IAs. The appropriate "status" field in the options MUST be set to indicate the reason for the release. The client sends the Release message to the All DHCP Agents multicast address through the interface for which the client is interested in releasing configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. A client MAY choose to wait for a Reply message from the server in response to the Release message. If the client does wait for a Reply, the client MAY choose to retransmit the Release message. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REL_MSG_ATTEMPTS MRT REP_MAX_RT MRD 0 The client MUST abandon the attempt to release addresses if the Release message exchange fails. The client MUST stop using all of the addresses in the IA(s) being released as soon as the client begins the Release message exchange process. If an IA is released but the Reply from a DHCP server is lost, the client will retransmit the Release message, and the server may respond with a Reply indicating a status of "Nobinding". Therefore, the client must not treat a Reply message with a status of "Nobinding" in a Release message exchange as if it indicates an error. Note that if the client fails to release the IA, the addresses assigned to the IA will be reclaimed by the server when the lease associated with it expires. 15.3.7. Receipt of Reply message in response to a Release message Upon receipt of a valid Reply message, the client can consider the Release event successful, and SHOULD return the successful status to the application layer, if an application initiated the release. 15.3.8. Creation and transmission of Decline messages The client sets the "msg-type" field to DECLINE. The client generates a transaction ID and places this value in the "transaction-ID" field. The client places the IP address of the server that allocated the address(es) in the "server-address" field. The client adds a DUID option to identify itself to the server. The client includes options containing the IAs it is declining in the "options" field. The addresses to be released MUST be included in the IAs. The appropriate "status" field in the options MUST be set to indicate the reason for declining the address. The client sends the Decline message to the All DHCP Agents multicast address through the interface for which the client is interested in declining addresses, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REL_ATTEMPTS MRT REP_MAX_RT MRD 0 The client MUST abandon the attempt to decline addresses if the Decline message exchange fails. 15.3.9. Receipt of Reply message in response to a Decline message Upon receipt of a valid Reply message, the client can consider the Decline event successful. [...] _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C13722.B5E8E780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCPv6 spec text for retransmission

Ralph:

See my comments inline below (prefixed by = BV>).

Please do look at my comments in 15.3.4 (also applies = to Renew). We have a protocol problem we likely need to correct!

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, September 04, 2001 9:49 PM
To: dhcwg@ietf.org
Subject: [dhcwg] DHCPv6 spec text for = retransmission


Here is the new text in the DHCPv6 spec describing = the
transmission and retransmission mechanism for = client
messages.  Thanks to Ted for writing the first = draft
of this text.

Notes:
* I chose +-0.0625 (2^-4) as the limits on = the
  randomization factor to (potentially) make = the
  arithmetic a little easier.  Perhaps I = misspent
  too much of my youth writing 8080 = assembler
  code and it's just not important to worry = about
  setting those limits around powers of = two.  If
  +-0.1 makes more sense, that's fine with = me.
BV> I'd go with +/- 0.1 because almost all = systems can do
BV> floating point math these days and you likely = need to
BV> anyway. If a system can't, it can always fall = back to
BV> a "close" approximatation (such as = +/- 0.0625).
* I did not choose to base the server
  Reconfigure-init retransmission = mechanism
  on section 13.  I don't think the DHCPv6 = spec
  needs to dictate the behavior of the server = when
  retransmitting Reconfigure-init = messages.
* There are some references to the use of IAs; = the
  new IA text has not been finalized and does = not
  yet appear in the doc.

Please review this new text and reply with = comments...

- Ralph

7.5. Configuration Variables

   This section presents a table of client = and server configuration
   variables and the default or initial = values for these variables.  The
   client-specific variables MAY be = configured on the server and MAY be
   delivered to the client through the = "DHCP Retransmission Parameter
   Option" in a Reply message.
BV> Didn't we want to drop this retransmission = parameter option
BV> since it opens up many cans of worms as per = the San Diego IETF?

      = Parameter      Default Description
   = -------------------------------------
   = MIN_SOL_DELAY          = ; 1 MIN (secs) to delay 1st mesg
   = MAX_SOL_DELAY          = ; 5 MAX (secs) to delay 1st mesg
   = ADV_TIMEOUT           = 500 SOL Retrans timer (msecs)
   = ADV_MAX_RT          &n= bsp;  30 MAX timer value (secs)
   = SOL_MAX_ATTEMPTS        0 MAX = attempts (0 =3D infinite)
   = REP_TIMEOUT           = 250 Retrans timer (msecs) for Reply
   = REP_MAX_RT          &n= bsp;   0 MAX Retrans time (0 =3D infinite)
   = REQ_MAX_ATTEMPTS       10 MAX = Request/Confirm/Renew/Rebind attempts
   = REL_MSG_ATTEMPTS        5 MAX = Release/Decline attempts
   = SRVR_PREF_WAIT          2 = Advertise Collect timer (secs)



13. Reliability of Client Initiated Message = Exchanges

   DHCP clients are responsible for = reliable delivery of messages in the
   client-initiated message exchanges = described in sections 14 and 15.
   If a DHCP client fails to receive an = expected response from a server,
   the client must retransmit its = message.  This section describes the
   retransmission strategy to be used by = clients in client-initiated
   message exchanges.

   The client begins the message exchange = by transmitting a message to
   the server.  The message exchange = terminates when either the client
   successfully receives the appropriate = response or responses from a
   server or servers, or when the message = exchange is considered to have
   failed according to the retransmission = mechanism described below.

   The client retransmission behavior is = controlled and describe by five
   variables:

      = RT     Retransmission timeout

      IRT    = Initial retransmission time

      MRC    = Maximum retransmission count

      MRT    = Maximum retransmission time

      MRD    = Maximum retransmission duration

      RAND   = Randomization factor

   With each message transmission or = retransmission, the client sets RT
   according to the rules given = below.  If RT expires before the message
   exchange terminates, the client = recomputes RT and retransmits the
   message.

   Each of the computations of a new RT = include a randomization factor
   (RAND), which is a random number chosen = with a uniform distribution
   between -0.0625 and +0.0625.  The = randomization factor is included
   to minimize synchronization of messages = transmitted by DHCP clients.
   The algorithm for choosing a random = number does not need to be
   cryptographically sound.  The = algorithm SHOULD produce a different
   sequence of numbers from each = invocation of the DHCP client.


   RT for the first message transmission is = based on IRT:

      RT =3D IRT + = RAND*IRT


   RT for each subsequent message = transmission is based on the previous
   value of RT:

      RT =3D RTprev + = RAND*RTprev


   MRT specifies an upper bound on the = value of RT. If MRT has a value
   of 0, there is no upper limit on the = value of RT. Otherwise:

    if (RT > MRT)
       RT =3D MRT + = RAND*MRT


   MRC specifies an upper bound on the = number of times a client may
   retransmit a message.  If MRC has = a value of 0, the client MUST
   continue to retransmit the original = message until a response is
   received.  Otherwise, the message = exchange fails if the client
   attempts to transmit the original = message more than MRC times.

   MRD specifies an upper bound on the = length of time a client may
   retransmit a message.  If MRD has = a value of 0, the client MUST
   continue to retransmit the original = message until a response is
   received.  Otherwise, the message = exchange fails if the client
   attempts to transmit the original = message more than MRD seconds.

BV> Just to be clear, might be good to say that = EITHER or BOTH of
BV> MRC or MRD can stop retransmissions? In most = cases it appears
BV> that only one is active, but it is always = possible that both
BV> could be.

14. DHCP Server Solicitation

   This section describes how a client = locates servers.  The behavior
   of client and server implementations is = discussed, along with the
   messages they use.

[...]

14.3. Client Behavior

   A client uses the Solicit message to = discover DHCP servers configured
   to serve addresses on the link to which = the client is attached.


14.3.1. Creation of Solicit messages

   The client sets the "msg-type" = field to SOLICIT. The client generates
   a transaction ID and inserts this value = in the "transaction-ID"
   field.
BV> While probably not something that is needed = in this section, we
BV> really don't have much text to describe the = "transaction-ID". All
BV> we generally say is to "generate a = transaction ID". However, we
BV> should make it clear to clients that they = should attempt to
BV> generate "unique" transaction ids. = Unique here is best if it is
BV> over a long period of time, but it must be = longer than any cache
BV> times in servers. Probably the best rule of = thumb is for clients
BV> to use to generate this number by = incrementing it. Then the only
BV> issue is what to set it to when (re)booting - = especially if there
BV> is no means to remember the last used = number.

   The client includes a DUID option to = identify itself to the server.
   The client MUST include options for any = IAs to which it wants the
   server to assign addresses.  The = client may include addresses in the
   IAs as a hint to the server about = addresses for which the client
   may have a preference.  The client = MAY include an Option Request
   Option in the Solicit message.  = The client MUST NOT include any other
   options except those specifically = allowed as defined by specific
   options.


14.3.2. Transmission of Solicit Messages

   The client sends the Solicit message to = the All DHCP Agents multicast
   address through the interface for which = the client is interested in
   obtaining configuration information, = with the destination port set
   to 547.  The source port selection = can be arbitrary, although it
   SHOULD be possible using a client = configuration facility to set a
   specific source port value.

   The client's first Solicit message on = the interface MUST be delayed
   by a random amount of time between = MIN_SOL_DELAY and MAX_SOL_DELAY.
   This random delay desynchronizes = clients which start at the same time
   (e.g., after a power outage).

   The client transmits the message = according to section 13, using the
   following parameters:

      IRT   = ADV_TIMEOUT

      MRC   = SOL_MAX_ATTEMPTS

      MRT   = ADV_MAX_RT

      MRD   = 0

   The mechanism in section 13 is modified = as follows for use in the
   transmission of Solicit messages.  = The message exchange is not
   terminated by the receipt of an = Advertise before ADV_MSG_TIMEOUT
BV> ADV_MSG_TIMEOUT doesn't exist. I think you = renamed it to
BV> ADV_TIMEOUT? ADV_MSG_TIMEOUT is used many = times.
   has elapsed.  Rather, the client = collects Advertise messages until
   ADV_MSG_TIMEOUT has elapsed.  The = first RT MUST be selected to be
   strictly greater than ADV_MSG_TIMEOUT = by choosing RAND to be strictly
   greater than 0.

   A DHCP client SHOULD choose MRC and MRT = to be 0.  If the DHCP
   client is otherwise configured, it MUST = stop trying to configure
   the interface if the message exchange = fails.  After the DHCP client
   stops trying to configure the = interface, it MAY choose to restart
   the reconfiguration process after some = external event, such as user
   input, system restart, or when the = client is attached to a new link.

BV> Did you mean MRD, not MRT? MRT limits the time = of a single
BV> retransmission. Also, the "If the DHCP = client is otherwise configured"
BV> made me re-read the paragraph several times. = Perhaps there is a better
BV> way to state this? "If the DHCP client = is configured with a non-zero
BV> MRC or MRD, ...".
BV> Oh, might you want to say = "SOL_MAX_ATTEMPTS" instead of MRC?

BV> Also, this Retransmit logic is a bit weird = beause of SRVR_PREF_WAIT.
BV> Does it make sense to state something like = "A client only retransmits
BV> a Solicit if it fails to receive any = Advertises before the retransmission
BV> timer expires. If a client receives one or = more Advertise messages, it
BV> then must wait SRVR_PERF_WAIT seconds from = the time of the transmit
BV> for any additional Advertise messages before = proceeding."

14.3.3. Receipt of Advertise messages

   A client MUST wait for SRVR_PREF_WAIT = seconds after sending a DHCP
   Solicit message to collect Advertise = messages, unless it receives an
   Advertise message with a preference = value of 255.  The preference
   value is carried in the Preference = option (section  19.5).  Any
   Solicit that does not include a = Preference option is considered to
   have a preference value of 0.  If = the client receives an Advertise
   message with a preference value of 255, = then the client MAY act
   immediately on that Advertise message = without waiting for any more
   additional Advertise messages.

   Upon receipt of one or more validated = Advertise messages, the client
   selects one or more Advertise messages = based upon the following
   criteria.

    -  Those Advertise messages = with the highest server preference value
       are preferred = over all other Advertise messages.

    -  Within a group of = Advertise messages with the same server
       preference = value, a client MAY select those servers whose
       Advertise = messages advertise information of interest to the
       client.  = For example, the client may choose a server that
       returned an = advertisement with configuration options of interest
       to the = client.

   Once a client has selected Advertise = message(s), the client will
   typically store information about each = server, such as server
   preference value, addresses advertised, = when the advertisement was
   received, and so on.  Depending on = the requirements of the client's
   invoking user, the client MAY initiate = a configuration exchange with
   the server(s) immediately, or MAY defer = this exchange until later.

   If the client needs to select an = alternate server in the case that a
   chosen server does not respond, the = client chooses the server with
   the next highest preference = value.

   The client MAY choose a less-preferred = server if that server has a
   better set of advertised parameters, = such as the available addresses
   advertised in IAs.

[...]

15. DHCP Client-Initiated Configuration = Exchange

[...]

15.3. Client Behavior

[...]

15.3.1. Creation and transmission of Request = messages

   If the client is using stateful address = configuration and needs either
   an initial set of addresses or = additional addresses, it MUST send
   a Request message to obtain new = addresses and other configuration
   information.  The client includes = one or more IAs in the Request
   message, to which the server assigns = new addresses.  The server then
   returns IA(s) to the client in a Reply = message.

   The client generates a transaction ID = and inserts this value in the
   "transaction-ID" = field.

   The client places the address of the = destination server in the
   "server-address" = field.

   The client adds a DUID option to = identify itself to the server.  The
   client adds any other appropriate = options, including one or more IA
   options (if the client is requesting = that the server assign it some
   network addresses).  The list of = addresses in each included IA MUST
   be empty.  If the client is not = requesting that the server assign it
   any addresses, the client omits the IA = option.

   The client sends the Request message to = the All DHCP Agents multicast
   address through the interface for which = the client is interested in
   obtaining configuration information, = with the destination port set
   to 547.  The source port selection = can be arbitrary, although it
   SHOULD be possible using a client = configuration facility to set a
   specific source port value.

   The client transmits the message = according to section 13, using the
   following parameters:

      IRT   = REP_TIMEOUT

      MRC   = REQ_MAX_ATTEMPTS

      MRT   = REP_MAX_RT

      MRD   = 0

   If the message exchange fails, the = client MAY choose one of the
   following actions:

    -  Select another server from = a list of servers known to the client;
       e.  g., = servers that responded with an Advertise message

    -  Initiate the server = discovery described in section 14

    -  Terminate the = configuration process and report failure


15.3.2. Creation and transmission of Confirm = messages

   Whenever a client may have moved to a = new link, its IPv6 addresses
   and other configuration information may = no longer be valid.  Examples
   of times when a client may have moved = to a new link include:

     o The client reboots

     o The client is physically = disconnected from a wired connection

     o The client returns from = sleep mode

     o The client using a = wireless technology changes cells

   In any situation when a client may have = moved to a new link, the
   client MUST initiate a Confirm/Reply = message exchange.  The client
   includes any IAs, along with the = addresses associated with those IAs,
   in its Confirm message.  Any = responding servers will indicate the
   acceptability of the addresses with the = status in the IA it returns
   to the client.

   The client sets the "msg-type" = field to CONFIRM. The client generates
   a transaction ID and inserts this value = in the "transaction-ID"
   field.

   The client sets the = "server-address" field to 0.

   The client adds a DUID option to = identify itself to the server.  The
   client adds any appropriate options, = including one or more IA options
   (if the client is requesting that the = server confirm the validity of
   some network addresses).  If the = client does include any IA options,
   it MUST include the list of addresses = the client currently has
   associated with that IA.

   The client sends the Confirm message to = the All DHCP Agents multicast
   address through the interface for which = the client is interested in
   confirming configuration information, = with the destination port set
   to 547.  The source port selection = can be arbitrary, although it
   SHOULD be possible using a client = configuration facility to set a
   specific source port value.

   The client transmits the message = according to section 13, using the
   following parameters:

      IRT   = REP_TIMEOUT

      MRC   = REQ_MSG_ATTEMPTS

      MRT   = REP_MAX_RT

      MRD   = 0

   If the message exchange fails, the = client MUST restart the
   configuration process by locating a = DHCP server as described
   in section 14.  The client SHOULD = report the failure of the
   configuration process to the = application layer.


15.3.3. Creation and transmission of Renew = messages

   IPv6 addresses assigned to a client = through an IA use the same
   preferred and valid lifetimes as IPv6 = addresses obtained through
   stateless autoconfiguration.  The = server assigns preferred and valid
   lifetimes to the IPv6 addresses it = assigns to an IA. To extend those
   lifetimes, the client sends a Request = to the server containing an
BV>         &nb= sp;           &nb= sp;         Renew!
   "IA option" for the IA and = its associated addresses.  The server
   determines new lifetimes for the = addresses in the IA according to the
   server's administrative = configuration.  The server may also add new
   addresses to the IA. The server may = remove addresses from the IA by
   setting the preferred and valid = lifetimes of those addresses to zero.
   The server controls the time at which = the client contacts the server
   to extend the lifetimes on assigned = addresses through the T1 and
   T2 parameters assigned to an IA. If the = server does not assign an
   explicit value to T1 or T2 for an IA, = T1 defaults to 0.5 times the
   shortest preferred lifetime of any = address assigned to the IA and
   T2 defaults to 0.875 times the shortest = preferred lifetime of any
   address assigned to the IA.
BV> Perhaps this is "not in this set of = edits", but I think we did
BV> decide to always have the server send T1/T2 = times. Therefore,
BV> there should be no need to have = "defaults".

   At time T1 for an IA, the client = initiates a Request/Reply message
   exchange to extend the lifetimes on any = addresses in the IA. The
   client includes an IA option with all = addresses currently assigned to
   the IA in its Request message.

   The client sets the "msg-type" = field to RENEW. The client generates a
   transaction ID and inserts this value = in the "transaction-ID" field.

   The client places the address of the = destination server in the
   "server-address" = field.

   The client adds a DUID option to = identify itself to the server.  The
   client adds any appropriate options, = including one or more IA options
   (if the client is requesting that the = server extend the lease on some
   IAs; note that the client may check the = status of other configuration
   parameters without asking for lease = extensions).  If the client does
   include any IA options, it MUST include = the list of addresses the
   client currently has associated with = that IA.

   The client sends the Renew message to = the All DHCP Agents multicast
   address through the interface for which = the client is interested
   in extending configuration information, = with the destination port
   set to 547.  The source port = selection can be arbitrary, although
   it SHOULD be possible using a client = configuration facility to set
   a specific source port value.  The = client transmits the message
   according to section 13, using the = following parameters:

      IRT   = REP_TIMEOUT

      MRC   = 0

      MRT   = REP_MAX_RT

      MRD   = 0

   The mechanism in section 13 is modified = as follows for use in the
   transmission of Renew messages.  = The message exchange is terminated
   when time T2 is reached (see section = 15.3.4), at which time the
   client begins a Rebind message = exchange.
BV> One can also set MRD =3D T2-T1. The only = issue there is that the
BV> recovery step from the timeout is to start a = REBIND. It should
BV> be noted that the REBIND is a new message and = not a retransmission
BV> and therefore a new transaction ID must be = chosen.

15.3.4. Creation and transmission of Rebind = messages

   At time T2 for an IA (which will only be = reached if the server to
   which the Renew message was sent at = time T1 has not responded),
   the client initiates a Rebind/Reply = message exchange.  The client
   includes an IA option with all = addresses currently assigned to the IA
   in its Rebind message.  The client = sends this message to the All DHCP
   Agents multicast address.

   The client sets the "msg-type" = field to REBIND. The client generates
   a transaction ID inserts this value in = the "transaction-ID" field.

   The client sets the = "server-address" field to 0.

   The client adds a DUID option to = identify itself to the server.
   The client adds any appropriate = options, including one or more IA
   options.  If the client does = include any IA options (if the client is
   requesting that the server extend the = lease on some IAs; note that
   the client may check the status of = other configuration parameters
   without asking for lease extensions), = it MUST include the list of
   addresses the client currently has = associated with that IA.

   The client sends the Rebind message to = the All DHCP Agents multicast
   address through the interface for which = the client is interested in
   extending configuration information, = with the destination port set
   to 547.  The source port selection = can be arbitrary, although it
   SHOULD be possible using a client = configuration facility to set a
   specific source port value.

   The client transmits the message = according to section 13, using the
   following parameters:

      IRT   = REP_TIMEOUT

      MRC   = 0

      MRT   = REP_MAX_RT

      MRD   = 0

   The mechanism in section 13 is modified = as follows for use in the
   transmission of Renew messages.  = The message exchange is terminated
   when the lease for the IA expires (see = section 11), at which time the
   client has several alternative actions = to choose from:
BV> Hum. This has some interesting problems (I = don't know what Section
BV> 11 refers to at this time, but don't recall = the -19 draft having
BV> much text in this area). The reason for the = interesting problems
BV> is because of the lifetime issue vs the T2 = and renewal time.
BV> What happens if an IA has two addresses. One = has a valid lifetime
BV> of 2 weeks. The other has a valid lifetime of = 3 days. The T2 time
BV> is 2 days. So, suppose the servers are = non-responsive for 4 days.
BV> When does the client stop retransmitting the = message? When does it
BV> alter it to remove the address with the = expired lifetime (after 3
BV> days). Does this change to the message mean = it MUST change the
BV> XID?
BV> I would suggest we say that MRD is = shortest-valid-lifetime - T2.
BV> Once that retransmission expires, the client = must generate a
BV> new Rebind message if there are *ANY* = addresses still valid. It
BV> stops only after all addresses are no longer = valid.
BV> We should also fix all the terminology such = as "when the lease
BV> on the IA expires"? It is really the = valid lifetimes on the
BV> individual addresses.
BV> NOTE: The above issue for Rebind is *ALSO* a = problem for Renew!
BV> What if you had a third address with a 1 day = valid lifetime
BV> and T1 was 12 hours. 12 hours into the renew = this third address
BV> is gone and should be removed from the Renew. = Hence, new message!
BV> Hence, new transaction ID. Messy, messy, = messy!

    -  When the lease on the IA = expires, the client may choose to use a
       Solicit message = to locate a new DHCP server and send a Request
       for the expired = IA to the new server

    -  Some addresses in the IA = may have lifetimes that extend beyond
       the lease of = the IA, so the client may choose to continue to use
       those = addresses; once all of the addresses have expired, the
       client may = choose to locate a new DHCP server
BV> Huh? How is this possible? There is no = "lease" to an IA. An IA
BV> dies when all of the addresses in that IA are = no longer valid. There
BV> is no other time that an IA dies. There is no = "expire" time.

    -  The client may have other = addresses in other IAs, so the client
       may choose to = discard the expired IA and use the addresses in the
       other = IAs


15.3.5. Receipt of Reply message in response to a = Request, Confirm,
   Renew or Rebind message

[...]

15.3.6. Creation and transmission of Release = messages

   The client sets the "msg-type" = field to RELEASE. The client generates
   a transaction ID and places this value = in the "transaction-ID" field.

   The client places the IP address of the = server that allocated the
   address(es) in the = "server-address" field.

   The client adds a DUID option to = identify itself to the server.  The
   client includes options containing the = IAs it is releasing in the
   "options" field.  The = addresses to be released MUST be included in
   the IAs.  The appropriate = "status" field in the options MUST be set
   to indicate the reason for the = release.

   The client sends the Release message to = the All DHCP Agents multicast
   address through the interface for which = the client is interested in
   releasing configuration information, = with the destination port set
   to 547.  The source port selection = can be arbitrary, although it
   SHOULD be possible using a client = configuration facility to set a
   specific source port value.

   A client MAY choose to wait for a Reply = message from the server in
   response to the Release message.  = If the client does wait for a
   Reply, the client MAY choose to = retransmit the Release message.

   The client transmits the message = according to section 13, using the
   following parameters:

      IRT   = REP_TIMEOUT

      MRC   = REL_MSG_ATTEMPTS

      MRT   = REP_MAX_RT

      MRD   = 0

   The client MUST abandon the attempt to = release addresses if the
   Release message exchange fails.

   The client MUST stop using all of the = addresses in the IA(s) being
   released as soon as the client begins = the Release message exchange
   process.  If an IA is released but = the Reply from a DHCP server
   is lost, the client will retransmit the = Release message, and the
   server may respond with a Reply = indicating a status of "Nobinding".
   Therefore, the client must not treat a = Reply message with a status
   of "Nobinding" in a Release = message exchange as if it indicates an
   error.

   Note that if the client fails to release = the IA, the addresses
   assigned to the IA will be reclaimed by = the server when the lease
   associated with it expires.


15.3.7. Receipt of Reply message in response to a = Release message

   Upon receipt of a valid Reply message, = the client can consider the
   Release event successful, and SHOULD = return the successful status to
   the application layer, if an = application initiated the release.


15.3.8. Creation and transmission of Decline = messages

   The client sets the "msg-type" = field to DECLINE. The client generates
   a transaction ID and places this value = in the "transaction-ID" field.

   The client places the IP address of the = server that allocated the
   address(es) in the = "server-address" field.

   The client adds a DUID option to = identify itself to the server.  The
   client includes options containing the = IAs it is declining in the
   "options" field.  The = addresses to be released MUST be included in
   the IAs.  The appropriate = "status" field in the options MUST be set
   to indicate the reason for declining = the address.

   The client sends the Decline message to = the All DHCP Agents multicast
   address through the interface for which = the client is interested
   in declining addresses, with the = destination port set to 547.  The
   source port selection can be arbitrary, = although it SHOULD be
   possible using a client configuration = facility to set a specific
   source port value.

   The client transmits the message = according to section 13, using the
   following parameters:

      IRT   = REP_TIMEOUT

      MRC   = REL_ATTEMPTS

      MRT   = REP_MAX_RT

      MRD   = 0

   The client MUST abandon the attempt to = decline addresses if the
   Decline message exchange fails.


15.3.9. Receipt of Reply message in response to a = Decline message

   Upon receipt of a valid Reply message, = the client can consider the
   Decline event successful.

[...]


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

------_=_NextPart_001_01C13722.B5E8E780-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 6 21:31:21 2001 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 VAA13293; Thu, 6 Sep 2001 21:31:21 -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 VAA13923; Thu, 6 Sep 2001 21:30:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13895 for ; Thu, 6 Sep 2001 21:30:43 -0400 (EDT) Received: from mail.tahoenetworks.com (nat2.tahoenetworks.com [63.99.114.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13241 for ; Thu, 6 Sep 2001 21:29:16 -0400 (EDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 6 Sep 2001 18:31:05 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1373C.C2840631" Date: Thu, 6 Sep 2001 18:31:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0149D1@TNEXVS02.tahoenetworks.com> Thread-Topic: load balancing RFC - what happens if you insert a new server? Thread-Index: AcE3PMJKgNcWWBCiTJKysfgnTdvn3g== From: "Lisa Guo" To: X-OriginalArrivalTime: 07 Sep 2001 01:31:05.0332 (UTC) FILETIME=[C310FB40:01C1373C] Subject: [dhcwg] load balancing RFC - what happens if you insert a new server? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1373C.C2840631 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I was looking for discussion on this on the archive website but couldn't find any, so if this has been discussed before, I apologize. =20 The load balancing RFC (3074) describes a hashing algorithm that is used by servers and relay agents to serve the clients in a deterministic way. I assume that the purpose is that the same server always serve the same client, from the initial discover/offer/request/ack to subsequent messages, such as renew, release, etc. What happens if a new server is added to the pool of servers that share the load? In order to use the new server, some of the hash bucket should be assigned to this new server now. But if one does that, messages related to an existing lease would be forwarded to the new server instead of the one that actually allocated the IP address in the first place. =20 Does anyone have a workaround on this? =20 Thanks, Lisa=20 ----------------------- Lisa Guo Tahoe Networks, Inc. ------_=_NextPart_001_01C1373C.C2840631 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
  = I was looking=20 for discussion on this on the archive website but
couldn't find any,=20 so if this has been discussed before, I apologize.
 
  = The load=20 balancing RFC (3074) describes a hashing algorithm = that
is = used by servers=20 and relay agents to serve the clients in a = deterministic
way. I = assume that=20 the purpose is that the same server always serve
the = same client,=20 from the initial discover/offer/request/ack to = subsequent
messages, such as=20 renew, release, etc. What happens if a new server
is = added to the pool=20 of servers that share the load? In order to use the
new = server, some of=20 the hash bucket should be assigned to this new
server = now. But if=20 one does that, messages related to an existing lease
would = be forwarded=20 to the new server instead of the one that actually
allocated the IP=20 address in the first place.
 
  = Does anyone=20 have a workaround on this?
 
Thanks,
Lisa
-----------------------
Lisa Guo
Tahoe Networks,=20 Inc.
------_=_NextPart_001_01C1373C.C2840631-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 6 22:22:30 2001 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 WAA14653; Thu, 6 Sep 2001 22:22:29 -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 WAA15046; Thu, 6 Sep 2001 22:21:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15021 for ; Thu, 6 Sep 2001 22:21:38 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14636 for ; Thu, 6 Sep 2001 22:20:10 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f872Lbp10807 for ; Thu, 6 Sep 2001 21:21:37 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f872Lb029394 for ; Thu, 6 Sep 2001 21:21:37 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Sep 06 21:21:36 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 21:21:36 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3554@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Lisa Guo'" , dhcwg@ietf.org Subject: RE: [dhcwg] load balancing RFC - what happens if you insert a new server? Date: Thu, 6 Sep 2001 21:21:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13743.D1886D00" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13743.D1886D00 Content-Type: text/plain; charset="iso-8859-1" Hi: It all depends on how the server works. If the server only applies the load balancing to NEW clients and not to renewals, then there really is no problem. That really was the intent of the protocol. Also, only broadcast packets are an issue as unicast datagrams are set to the server in question. Section 3 of RFC 3074 says: Because DHCP clients use UDP broadcasts to contact DHCP servers, a client DHCPDISCOVER message may be received by more than one server. All servers receiving such a broadcast may respond to the client, letting the client choose which server it will use. There likely will be a revision of this RFC shortly when the DHCPv6 DUID is defined to support load balancing for DHCP for IPv6 as well. Perhaps during that revision (new Internet-Draft), we can be a bit clearer as to the proper use of this. - Bernie Volz PS: Note also that for IPv6, while most client generated packets are multicast, the target server is specified when the message is destined for a particular server and that server should process that message regardless of what the load balancing says. -----Original Message----- From: Lisa Guo [mailto:lguo@tahoenetworks.com] Sent: Thursday, September 06, 2001 9:31 PM To: dhcwg@ietf.org Subject: [dhcwg] load balancing RFC - what happens if you insert a new server? Hi, I was looking for discussion on this on the archive website but couldn't find any, so if this has been discussed before, I apologize. The load balancing RFC (3074) describes a hashing algorithm that is used by servers and relay agents to serve the clients in a deterministic way. I assume that the purpose is that the same server always serve the same client, from the initial discover/offer/request/ack to subsequent messages, such as renew, release, etc. What happens if a new server is added to the pool of servers that share the load? In order to use the new server, some of the hash bucket should be assigned to this new server now. But if one does that, messages related to an existing lease would be forwarded to the new server instead of the one that actually allocated the IP address in the first place. Does anyone have a workaround on this? Thanks, Lisa ----------------------- Lisa Guo Tahoe Networks, Inc. ------_=_NextPart_001_01C13743.D1886D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] load balancing RFC - what happens if you insert a = new server?

Hi:

It all depends on how the server works. If the server = only applies the load balancing to NEW clients and not to renewals, = then there really is no problem. That really was the intent of the = protocol. Also, only broadcast packets are an issue as unicast = datagrams are set to the server in question.

Section 3 of RFC 3074 says:

   Because DHCP clients use UDP broadcasts = to contact DHCP servers, a
   client DHCPDISCOVER message may be = received by more than one server.
   All servers receiving such a broadcast = may respond to the client,
   letting the client choose which server = it will use.

There likely will be a revision of this RFC shortly = when the DHCPv6 DUID is defined to support load balancing for DHCP for = IPv6 as well. Perhaps during that revision (new Internet-Draft), we can = be a bit clearer as to the proper use of this.

- Bernie Volz

PS: Note also that for IPv6, while most client = generated packets are multicast, the target server is specified when = the message is destined for a particular server and that server should = process that message regardless of what the load balancing = says.

-----Original Message-----
From: Lisa Guo [mailto:lguo@tahoenetworks.com= ]
Sent: Thursday, September 06, 2001 9:31 PM
To: dhcwg@ietf.org
Subject: [dhcwg] load balancing RFC - what happens = if you insert a new server?


Hi,

  I was looking for discussion on this on the = archive website but
couldn't find any, so if this has been discussed = before, I apologize.

  The load balancing RFC (3074) describes a = hashing algorithm that
is used by servers and relay agents to serve the = clients in a deterministic
way. I assume that the purpose is that the same = server always serve
the same client, from the initial = discover/offer/request/ack to subsequent
messages, such as renew, release, etc. What happens = if a new server
is added to the pool of servers that share the load? = In order to use the
new server, some of the hash bucket should be = assigned to this new
server now. But if one does that, messages related = to an existing lease
would be forwarded to the new server instead of the = one that actually
allocated the IP address in the first place.

  Does anyone have a workaround on this?

Thanks,
Lisa
-----------------------
Lisa Guo
Tahoe Networks, Inc.

------_=_NextPart_001_01C13743.D1886D00-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 6 22:48:58 2001 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 WAA15952; Thu, 6 Sep 2001 22:48:58 -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 WAA15777; Thu, 6 Sep 2001 22:47:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15754 for ; Thu, 6 Sep 2001 22:47:27 -0400 (EDT) Received: from mail.tahoenetworks.com (nat2.tahoenetworks.com [63.99.114.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15922 for ; Thu, 6 Sep 2001 22:45:59 -0400 (EDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 6 Sep 2001 19:47:48 -0700 content-class: urn:content-classes:message Subject: RE: [dhcwg] load balancing RFC - what happens if you insert a new server? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13747.7890EE24" Date: Thu, 6 Sep 2001 19:47:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1FE1D2@TNEXVS02.tahoenetworks.com> Thread-Topic: [dhcwg] load balancing RFC - what happens if you insert a new server? Thread-Index: AcE3Q+FnlFrs2E14SrCmpGpm4bVBWQAA39VQ From: "Lisa Guo" To: "Bernie Volz (EUD)" , X-OriginalArrivalTime: 07 Sep 2001 02:47:48.0870 (UTC) FILETIME=[7AFD2260:01C13747] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C13747.7890EE24 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, September 06, 2001 7:22 PM To: Lisa Guo; dhcwg@ietf.org Subject: RE: [dhcwg] load balancing RFC - what happens if you insert a new server? Hi:=20 It all depends on how the server works. If the server only applies the load balancing to NEW clients and not to renewals, then there really is no problem. That really was the intent of the protocol. Also, only broadcast packets are an issue as unicast datagrams are set to the server in question.=20 You are right. I missed that part.=20 Thanks, Lisa ------_=_NextPart_001_01C13747.7890EE24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] load balancing RFC - what happens if you insert a new = server?
 
-----Original Message-----
From: Bernie Volz (EUD)=20 [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday, = September 06,=20 2001 7:22 PM
To: Lisa Guo; dhcwg@ietf.org
Subject: = RE:=20 [dhcwg] load balancing RFC - what happens if you insert a new=20 server?

Hi:

It all depends on how the server works. If the = server only=20 applies the load balancing to NEW clients and not to renewals, then = there=20 really is no problem. That really was the intent of the protocol. = Also, only=20 broadcast packets are an issue as unicast datagrams are set to the = server in=20 question. 

You are right. I missed that = part. 

Thanks,

Lisa

------_=_NextPart_001_01C13747.7890EE24-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 7 07:42:29 2001 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 HAA07329; Fri, 7 Sep 2001 07:42:28 -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 HAA06782; Fri, 7 Sep 2001 07:41:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06756 for ; Fri, 7 Sep 2001 07:41:20 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07200 for ; Fri, 7 Sep 2001 07:39:52 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-88.cisco.com [10.82.240.88]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA01650; Fri, 7 Sep 2001 07:40:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20010907073207.039cb948@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Sep 2001 07:40:28 -0400 To: "Bernie Volz (EUD)" From: Ralph Droms Subject: RE: [dhcwg] DHCPv6 spec text for retransmission Cc: dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC697B354D@eambunt705.ena-east .ericsson.se> 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: X-BeenThere: dhcwg@ietf.org The quick (and evasive, on my part!) answer to your concern about 15.3.4 is that the definition and semantics of an IA are in flux. The new text on IAs that you, Mark and Ted are working on should clarify what's needed in 15.3.4 and elsewhere. I expect to have to make revisions throughout the rest of the doc once we have firm text on IAs. - Ralph At 05:24 PM 9/6/2001 -0500, Bernie Volz (EUD) wrote: >Ralph: > >See my comments inline below (prefixed by BV>). > >Please do look at my comments in 15.3.4 (also applies to Renew). We have a protocol problem we likely need to correct! (remainder of Bernie's message deleted - RD) _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 7 07:55:49 2001 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 HAA08092; Fri, 7 Sep 2001 07:55:48 -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 HAA06980; Fri, 7 Sep 2001 07:54:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06955 for ; Fri, 7 Sep 2001 07:54:47 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07995 for ; Fri, 7 Sep 2001 07:53:19 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-88.cisco.com [10.82.240.88]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA02805 for ; Fri, 7 Sep 2001 07:54:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20010907074045.00b6cf90@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Sep 2001 07:54:02 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] DHCPv6 spec text for retransmission 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: X-BeenThere: dhcwg@ietf.org My responses to Bernie's comments are inline (prefixed by RD>). I've deleted much of the text that Bernie didn't comment on. - Ralph ===== Ralph: See my comments inline below (prefixed by BV>). Please do look at my comments in 15.3.4 (also applies to Renew). We have a protocol problem we likely need to correct! -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, September 04, 2001 9:49 PM To: dhcwg@ietf.org Subject: [dhcwg] DHCPv6 spec text for retransmission Here is the new text in the DHCPv6 spec describing the transmission and retransmission mechanism for client messages. Thanks to Ted for writing the first draft of this text. Notes: * I chose +-0.0625 (2^-4) as the limits on the randomization factor to (potentially) make the arithmetic a little easier. Perhaps I misspent too much of my youth writing 8080 assembler code and it's just not important to worry about setting those limits around powers of two. If +-0.1 makes more sense, that's fine with me. BV> I'd go with +/- 0.1 because almost all systems can do BV> floating point math these days and you likely need to BV> anyway. If a system can't, it can always fall back to BV> a "close" approximatation (such as +/- 0.0625). RD> OK - maybe a "SHOULD" (with some add'l text) RD> rather than a "MUST" RD> for clarity * I did not choose to base the server Reconfigure-init retransmission mechanism on section 13. I don't think the DHCPv6 spec needs to dictate the behavior of the server when retransmitting Reconfigure-init messages. * There are some references to the use of IAs; the new IA text has not been finalized and does not yet appear in the doc. Please review this new text and reply with comments... - Ralph 7.5. Configuration Variables This section presents a table of client and server configuration variables and the default or initial values for these variables. The client-specific variables MAY be configured on the server and MAY be delivered to the client through the "DHCP Retransmission Parameter Option" in a Reply message. BV> Didn't we want to drop this retransmission parameter option BV> since it opens up many cans of worms as per the San Diego IETF? RD>Right; I'll delete this text. Parameter Default Description ------------------------------------- MIN_SOL_DELAY 1 MIN (secs) to delay 1st mesg MAX_SOL_DELAY 5 MAX (secs) to delay 1st mesg ADV_TIMEOUT 500 SOL Retrans timer (msecs) ADV_MAX_RT 30 MAX timer value (secs) SOL_MAX_ATTEMPTS 0 MAX attempts (0 = infinite) REP_TIMEOUT 250 Retrans timer (msecs) for Reply REP_MAX_RT 0 MAX Retrans time (0 = infinite) REQ_MAX_ATTEMPTS 10 MAX Request/Confirm/Renew/Rebind attempts REL_MSG_ATTEMPTS 5 MAX Release/Decline attempts SRVR_PREF_WAIT 2 Advertise Collect timer (secs) 13. Reliability of Client Initiated Message Exchanges [...] MRC specifies an upper bound on the number of times a client may retransmit a message. If MRC has a value of 0, the client MUST continue to retransmit the original message until a response is received. Otherwise, the message exchange fails if the client attempts to transmit the original message more than MRC times. MRD specifies an upper bound on the length of time a client may retransmit a message. If MRD has a value of 0, the client MUST continue to retransmit the original message until a response is received. Otherwise, the message exchange fails if the client attempts to transmit the original message more than MRD seconds. BV> Just to be clear, might be good to say that EITHER or BOTH of BV> MRC or MRD can stop retransmissions? In most cases it appears BV> that only one is active, but it is always possible that both BV> could be. RD> OK. 14. DHCP Server Solicitation This section describes how a client locates servers. The behavior of client and server implementations is discussed, along with the messages they use. [...] 14.3. Client Behavior A client uses the Solicit message to discover DHCP servers configured to serve addresses on the link to which the client is attached. 14.3.1. Creation of Solicit messages The client sets the "msg-type" field to SOLICIT. The client generates a transaction ID and inserts this value in the "transaction-ID" field. BV> While probably not something that is needed in this section, we BV> really don't have much text to describe the "transaction-ID". All BV> we generally say is to "generate a transaction ID". However, we BV> should make it clear to clients that they should attempt to BV> generate "unique" transaction ids. Unique here is best if it is BV> over a long period of time, but it must be longer than any cache BV> times in servers. Probably the best rule of thumb is for clients BV> to use to generate this number by incrementing it. Then the only BV> issue is what to set it to when (re)booting - especially if there BV> is no means to remember the last used number. RD>OK, I'll add text as you suggest... The client includes a DUID option to identify itself to the server. The client MUST include options for any IAs to which it wants the server to assign addresses. The client may include addresses in the IAs as a hint to the server about addresses for which the client may have a preference. The client MAY include an Option Request Option in the Solicit message. The client MUST NOT include any other options except those specifically allowed as defined by specific options. 14.3.2. Transmission of Solicit Messages The client sends the Solicit message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client's first Solicit message on the interface MUST be delayed by a random amount of time between MIN_SOL_DELAY and MAX_SOL_DELAY. This random delay desynchronizes clients which start at the same time (e.g., after a power outage). The client transmits the message according to section 13, using the following parameters: IRT ADV_TIMEOUT MRC SOL_MAX_ATTEMPTS MRT ADV_MAX_RT MRD 0 The mechanism in section 13 is modified as follows for use in the transmission of Solicit messages. The message exchange is not terminated by the receipt of an Advertise before ADV_MSG_TIMEOUT BV> ADV_MSG_TIMEOUT doesn't exist. I think you renamed it to BV> ADV_TIMEOUT? ADV_MSG_TIMEOUT is used many times. RD>Right; good catch. I'll make those changes... has elapsed. Rather, the client collects Advertise messages until ADV_MSG_TIMEOUT has elapsed. The first RT MUST be selected to be strictly greater than ADV_MSG_TIMEOUT by choosing RAND to be strictly greater than 0. A DHCP client SHOULD choose MRC and MRT to be 0. If the DHCP client is otherwise configured, it MUST stop trying to configure the interface if the message exchange fails. After the DHCP client stops trying to configure the interface, it MAY choose to restart the reconfiguration process after some external event, such as user input, system restart, or when the client is attached to a new link. BV> Did you mean MRD, not MRT? MRT limits the time of a single BV> retransmission. Also, the "If the DHCP client is otherwise configured" BV> made me re-read the paragraph several times. Perhaps there is a better BV> way to state this? "If the DHCP client is configured with a non-zero BV> MRC or MRD, ...". BV> Oh, might you want to say "SOL_MAX_ATTEMPTS" instead of MRC? RD>Yeah; on rereading, this isn't exactly clear. I'll fix RD>it. BV> Also, this Retransmit logic is a bit weird beause of SRVR_PREF_WAIT. BV> Does it make sense to state something like "A client only retransmits BV> a Solicit if it fails to receive any Advertises before the retransmission BV> timer expires. If a client receives one or more Advertise messages, it BV> then must wait SRVR_PERF_WAIT seconds from the time of the transmit BV> for any additional Advertise messages before proceeding." RD>OK... 14.3.3. Receipt of Advertise messages [...] 15. DHCP Client-Initiated Configuration Exchange [...] 15.3. Client Behavior [...] 15.3.1. Creation and transmission of Request messages [...] 15.3.2. Creation and transmission of Confirm messages [...] 15.3.3. Creation and transmission of Renew messages IPv6 addresses assigned to a client through an IA use the same preferred and valid lifetimes as IPv6 addresses obtained through stateless autoconfiguration. The server assigns preferred and valid lifetimes to the IPv6 addresses it assigns to an IA. To extend those lifetimes, the client sends a Request to the server containing an BV> Renew! RD>OK. "IA option" for the IA and its associated addresses. The server determines new lifetimes for the addresses in the IA according to the server's administrative configuration. The server may also add new addresses to the IA. The server may remove addresses from the IA by setting the preferred and valid lifetimes of those addresses to zero. The server controls the time at which the client contacts the server to extend the lifetimes on assigned addresses through the T1 and T2 parameters assigned to an IA. If the server does not assign an explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the shortest preferred lifetime of any address assigned to the IA and T2 defaults to 0.875 times the shortest preferred lifetime of any address assigned to the IA. BV> Perhaps this is "not in this set of edits", but I think we did BV> decide to always have the server send T1/T2 times. Therefore, BV> there should be no need to have "defaults". RD>Yeah - I'm waiting until text on IA format and semantics is RD>complete before doing final text here. At time T1 for an IA, the client initiates a Request/Reply message exchange to extend the lifetimes on any addresses in the IA. The client includes an IA option with all addresses currently assigned to the IA in its Request message. The client sets the "msg-type" field to RENEW. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client places the address of the destination server in the "server-address" field. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options (if the client is requesting that the server extend the lease on some IAs; note that the client may check the status of other configuration parameters without asking for lease extensions). If the client does include any IA options, it MUST include the list of addresses the client currently has associated with that IA. The client sends the Renew message to the All DHCP Agents multicast address through the interface for which the client is interested in extending configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC 0 MRT REP_MAX_RT MRD 0 The mechanism in section 13 is modified as follows for use in the transmission of Renew messages. The message exchange is terminated when time T2 is reached (see section 15.3.4), at which time the client begins a Rebind message exchange. BV> One can also set MRD = T2-T1. The only issue there is that the BV> recovery step from the timeout is to start a REBIND. It should BV> be noted that the REBIND is a new message and not a retransmission BV> and therefore a new transaction ID must be chosen. RD>I thought it was simpler to just use T1 and T2 directly RD>rather than adjusting MRD. I'll make the note about RD>the transaction ID. 15.3.4. Creation and transmission of Rebind messages [comments on 15.3.4 waiting for text on IAs...] 15.3.5. Receipt of Reply message in response to a Request, Confirm, Renew or Rebind message [...] 15.3.6. Creation and transmission of Release messages [...] 15.3.7. Receipt of Reply message in response to a Release message [...] 15.3.8. Creation and transmission of Decline messages [...] 15.3.9. Receipt of Reply message in response to a Decline message [...] b _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 8 13:00:03 2001 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 NAA27498; Sat, 8 Sep 2001 13:00:03 -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 MAA28431; Sat, 8 Sep 2001 12:59:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28411 for ; Sat, 8 Sep 2001 12:59:07 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27478 for ; Sat, 8 Sep 2001 12:57:39 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA12878; Sat, 8 Sep 2001 12:58:59 -0400 (EDT) Message-ID: <3B9A4E53.710796E0@cs.columbia.edu> Date: Sat, 08 Sep 2001 12:58:59 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Ted Lemon CC: Thomas Narten , dhcwg@ietf.org Subject: Re: [dhcwg] How to encode DNS labels in DHCP options References: <200109042158.f84Lw4s00342@grosse.bisbee.fugue.com> 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: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I think in practice, this only moves the problem around. It seems unlikely that configuration files for DHCP servers would force users to enter RFC 1035 notation. Among other things, it is rather likely to cause errors. (Forget to update the count byte when you change a label and you've introduced some rather strange results.) Thus, I would expect that actual servers will use some higher-level character set that can express IDN names, say, UTF-8 and then internally translate. If that's the case, it really doesn't much matter where the translation takes place. It does matter if the standard OS interfaces expect UTF-8, say, since most applications will need this. In that case, you'll do the translation twice. The client gets the RFC 1035 string from DHCP, translates it into UTF-8 so that the client OS understands it and then this gets translated again by the resolver library back into RFC 1035 for the on-the-wire format. I know of no current resolver library that allows you to specify RFC 1035 labels as input, but I obviously haven't done a complete survey. Can be done, but hasn't accomplished much in terms of avoiding translation errors, since you have two translations instead of one. One can only hope that both translation directions are one-to-one, otherwise you could get some peculiar results. Ted Lemon wrote: > > The idea of using the RFC1035 encoding is that it is exactly what the > DNS protocol currently specifies. This means that if we use this > format, we don't have to worry that it will be our fault that the > encoding doesn't work. When IDN happens, it will presumably work on > top of the existing packet format, so that means that what we have > specified should also work. > > So IMHO any new DHCP option that contains a domain name should use the > RFC1035 format. I can't remember the details with SIP, but I *think* > that what is being encoded is not a domain name, and that is the > reason for the difference. > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 8 16:47:33 2001 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 QAA29481; Sat, 8 Sep 2001 16:47:33 -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 QAA02522; Sat, 8 Sep 2001 16:47:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02497 for ; Sat, 8 Sep 2001 16:47:03 -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 QAA29464 for ; Sat, 8 Sep 2001 16:45:35 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-228.ip.theriver.com [205.140.116.228]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f88Kkqf03863; Sat, 8 Sep 2001 13:46:53 -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 f88KiLA01840; Sat, 8 Sep 2001 13:44:21 -0700 (MST) Message-Id: <200109082044.f88KiLA01840@grosse.bisbee.fugue.com> To: "Henning G. Schulzrinne" cc: Thomas Narten , dhcwg@ietf.org Subject: Re: [dhcwg] How to encode DNS labels in DHCP options In-Reply-To: Message from "Henning G. Schulzrinne" of "Sat, 08 Sep 2001 12:58:59 -0400." <3B9A4E53.710796E0@cs.columbia.edu> Date: Sat, 08 Sep 2001 13:44:21 -0700 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > I think in practice, this only moves the problem around. It seems > unlikely that configuration files for DHCP servers would force users to > enter RFC 1035 notation. Among other things, it is rather likely to > cause errors. (Forget to update the count byte when you change a label > and you've introduced some rather strange results.) Of course the DHCP server doesn't have to force the user to enter protocol level information directly. And you are right that this moves the problem around. It moves it to where it can be appropriately handled - the application's user interface. The protocol has to be *able* to encode IDN when/if IDN materializes. We do not need to say how an application presents this to the user. We can safely leave that to the IDN people. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Sep 9 09:38:29 2001 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 JAA10230; Sun, 9 Sep 2001 09:38:29 -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 JAA24037; Sun, 9 Sep 2001 09:36:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24011 for ; Sun, 9 Sep 2001 09:36:38 -0400 (EDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10218 for ; Sun, 9 Sep 2001 09:34:53 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel1.hp.com (Postfix) with ESMTP id 5D956AB5 for ; Sun, 9 Sep 2001 06:36:19 -0700 (PDT) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id TAA06635 for ; Sun, 9 Sep 2001 19:02:58 +0530 (IST) Reply-To: From: "Vijay Bhaskar A K" To: Date: Sun, 9 Sep 2001 19:06:18 +0530 Message-ID: <000001c13934$68773510$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 Port numbers Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit The DHCPv6 draft says that, the port numbers for client and agents are given as 546 & 547. Are these port numbers are already registered to IANA? If not, who is supposed to register these port numbers to IANA? ~Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Sep 9 10:05:17 2001 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 KAA10560; Sun, 9 Sep 2001 10:05:17 -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 KAA24466; Sun, 9 Sep 2001 10:04:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24443 for ; Sun, 9 Sep 2001 10:04:01 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10540 for ; Sun, 9 Sep 2001 10:02:22 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f89E3np26578 for ; Sun, 9 Sep 2001 09:03:49 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f89E3nD00658 for ; Sun, 9 Sep 2001 09:03:49 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun Sep 09 09:03:48 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 9 Sep 2001 09:03:47 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3562@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , Dhcwg@ietf.org Subject: RE: [dhcwg] DHCPv6 Port numbers Date: Sun, 9 Sep 2001 09:03:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13938.3E896CB0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13938.3E896CB0 Content-Type: text/plain; charset="iso-8859-1" See http://www.iana.org/assignments/port-numbers: dhcpv6-client 546/tcp DHCPv6 Client dhcpv6-client 546/udp DHCPv6 Client dhcpv6-server 547/tcp DHCPv6 Server dhcpv6-server 547/udp DHCPv6 Server # Jim Bound -----Original Message----- From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Sunday, September 09, 2001 9:36 AM To: Dhcwg@ietf.org Subject: [dhcwg] DHCPv6 Port numbers The DHCPv6 draft says that, the port numbers for client and agents are given as 546 & 547. Are these port numbers are already registered to IANA? If not, who is supposed to register these port numbers to IANA? ~Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C13938.3E896CB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCPv6 Port numbers

See = http://www.iana.org/assignments/port-numbers:

dhcpv6-client   546/tcp    = DHCPv6 Client
dhcpv6-client   546/udp    = DHCPv6 Client
dhcpv6-server   547/tcp    = DHCPv6 Server
dhcpv6-server   547/udp    = DHCPv6 Server
#          &n= bsp;           &n= bsp;   Jim Bound <bound@zk3.dec.com>

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Sunday, September 09, 2001 9:36 AM
To: Dhcwg@ietf.org
Subject: [dhcwg] DHCPv6 Port numbers


The DHCPv6 draft says that, the port numbers for = client and
agents are given as 546 & 547. Are these port = numbers are already
registered to IANA? If not, who is supposed to = register these
port numbers to IANA?
~Vijay


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

------_=_NextPart_001_01C13938.3E896CB0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 12 15:11:04 2001 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 PAA00767; Wed, 12 Sep 2001 15:11:04 -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 PAA06329; Wed, 12 Sep 2001 15:09:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06298 for ; Wed, 12 Sep 2001 15:09:21 -0400 (EDT) Received: from 3miasto.net (root@3miasto.net [217.96.12.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00682 for ; Wed, 12 Sep 2001 15:07:53 -0400 (EDT) Received: from scope (pc64.gdynia.sdi.tpnet.pl [213.77.131.64]) by 3miasto.net (8.11.6/8.11.0) with ESMTP id f8CJ7TY23242 for ; Wed, 12 Sep 2001 21:07:29 +0200 Date: Wed, 12 Sep 2001 21:06:54 +0200 From: Artur Guja X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: Artur Guja X-Priority: 3 (Normal) Message-ID: <63297143.20010912210654@3miasto.net> To: Dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] server behaviour for Decline Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi, What is the server behaviour upon recieving the Decline message? This message seems to be generaly poorly defined. Or have I missed something? Artur Guja _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 12 15:42:27 2001 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 PAA01388; Wed, 12 Sep 2001 15:42:27 -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 PAA07271; Wed, 12 Sep 2001 15:41:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07248 for ; Wed, 12 Sep 2001 15:41:49 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01366 for ; Wed, 12 Sep 2001 15:41:19 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f8CJfM714695 for ; Wed, 12 Sep 2001 14:41:22 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8CJfMs02345 for ; Wed, 12 Sep 2001 14:41:22 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Sep 12 14:41:21 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Sep 2001 14:41:20 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B359C@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Artur Guja'" , Dhcwg@ietf.org Subject: RE: [dhcwg] server behaviour for Decline Date: Wed, 12 Sep 2001 14:41:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13BC2.E47F3280" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13BC2.E47F3280 Content-Type: text/plain; charset="iso-8859-1" An updated draft is in the works. The Decline basically could be used for one reasons ... if one or more addresses is "in use" by another node on the link (discovered via Duplicate Address Detection). The server should remove that address (or addresses) from the client's IA and "mark" the address as in possible conflict. - Bernie -----Original Message----- From: Artur Guja [mailto:skybird@3miasto.net] Sent: Wednesday, September 12, 2001 3:07 PM To: Dhcwg@ietf.org Subject: [dhcwg] server behaviour for Decline Hi, What is the server behaviour upon recieving the Decline message? This message seems to be generaly poorly defined. Or have I missed something? Artur Guja _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C13BC2.E47F3280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] server behaviour for Decline

An updated draft is in the works.

The Decline basically could be used for one reasons = ... if one or more addresses is "in use" by another node on = the link (discovered via Duplicate Address Detection).

The server should remove that address (or addresses) = from the client's IA and "mark" the address as in possible = conflict.

- Bernie

-----Original Message-----
From: Artur Guja [mailto:skybird@3miasto.net]
Sent: Wednesday, September 12, 2001 3:07 PM
To: Dhcwg@ietf.org
Subject: [dhcwg] server behaviour for Decline


Hi,

What is the server behaviour upon recieving the = Decline message?
This message seems to be generaly poorly = defined.

Or have I missed something?

Artur Guja



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

------_=_NextPart_001_01C13BC2.E47F3280-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 14 10:49:06 2001 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 KAA19098; Fri, 14 Sep 2001 10:49:06 -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 KAA00467; Fri, 14 Sep 2001 10:40:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00440 for ; Fri, 14 Sep 2001 10:40:22 -0400 (EDT) Received: from alageremail2.agere.com (alageremail2.agere.com [192.19.192.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18967 for ; Fri, 14 Sep 2001 10:40:50 -0400 (EDT) Received: from rderelay.agere.com (rderelay.agere.com [135.15.172.48]) by alageremail2.agere.com (8.9.1/8.9.3) with ESMTP id KAA12725 for ; Fri, 14 Sep 2001 10:40:14 -0400 (EDT) Received: from alcmail.agere.com by rderelay.agere.com (8.9.3+Sun/EMS-1.5 sol2) id KAA21402 for ; Fri, 14 Sep 2001 10:36:59 -0400 (EDT) Received: from PAI820RyanChen by alcmail.agere.com (8.9.3+Sun/EMS-1.5 sol2) id KAA04974; Fri, 14 Sep 2001 10:39:51 -0400 (EDT) Message-ID: <003701c13d2b$1af386e0$242b5e80@PAI820RyanChen> From: "Yu \(Ryan\) Chen" To: Date: Fri, 14 Sep 2001 10:39:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [dhcwg] dhcp-aaa Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi, can anyone tell me where I can find detail protocol of interaction between DHCP and AAA. Is that a complete work or in progress? The internet draft I found only have abstract description. Thanks, Ryan _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 14 11:25:20 2001 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 LAA19951; Fri, 14 Sep 2001 11:25:19 -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 LAA01616; Fri, 14 Sep 2001 11:21:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01596 for ; Fri, 14 Sep 2001 11:21:04 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19892 for ; Fri, 14 Sep 2001 11:21:30 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8EFJwp27628 for ; Fri, 14 Sep 2001 11:19:58 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 14 Sep 2001 11:20:10 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Sep 2001 11:20:12 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C019C31AD@zcard031.ca.nortel.com> From: "Biswaroop Mukherjee" To: "Yu (Ryan) Chen" , dhcwg Subject: RE: [dhcwg] dhcp-aaa Date: Fri, 14 Sep 2001 11:20:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13D30.C2E6E180" X-Orig: Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13D30.C2E6E180 Content-Type: text/plain; charset="iso-8859-1" Check out "Extensions to DHCP for Roaming Users ". http://search.ietf.org/internet-drafts/draft-ietf-dhc-dhcproam-00.txt -- Roop ___________________________________________________________ The contents of this email are Nortel Networks Confidential > -----Original Message----- > From: Yu (Ryan) Chen [mailto:yrchen@agere.com] > Sent: Friday, September 14, 2001 10:40 AM > To: dhcwg > Subject: [dhcwg] dhcp-aaa > > > Hi, can anyone tell me where I can find > detail protocol of interaction between DHCP and AAA. > Is that a complete work or in progress? > The internet draft I found only have abstract description. > > Thanks, > Ryan > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C13D30.C2E6E180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcp-aaa

Check out "Extensions to DHCP for Roaming Users = <draft-ietf-dhc-dhcproam-00.txt>".
http://search.ietf.org/internet-drafts/draft-ietf-dhc-= dhcproam-00.txt

-- Roop
___________________________________________________________
The contents of this email are Nortel Networks = Confidential

> -----Original Message-----
> From: Yu (Ryan) Chen [mailto:yrchen@agere.com]
> Sent: Friday, September 14, 2001 10:40 = AM
> To: dhcwg
> Subject: [dhcwg] dhcp-aaa
>
>
> Hi, can anyone tell me where I can find
> detail protocol of interaction between DHCP and = AAA.
> Is that a complete work or in progress?
> The internet draft I found only have abstract = description.
>
> Thanks,
> Ryan
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> http://www1.ietf.org/mailman/listinfo/dhcwg=
>

------_=_NextPart_001_01C13D30.C2E6E180-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 14 12:09:21 2001 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 MAA20981; Fri, 14 Sep 2001 12:09:21 -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 MAA03698; Fri, 14 Sep 2001 12:07:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03673 for ; Fri, 14 Sep 2001 12:07:20 -0400 (EDT) Received: from extmail02m.raleigh.ibm.com (extmail02.raleigh.ibm.com [204.146.167.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20933 for ; Fri, 14 Sep 2001 12:07:48 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [192.168.1.108]) by extmail02m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id MAA24588 for ; Fri, 14 Sep 2001 12:05:55 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id MAA25094 for ; Fri, 14 Sep 2001 12:06:49 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id MAA28109 for ; Fri, 14 Sep 2001 12:04:03 -0400 Message-Id: <200109141604.MAA28109@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Fri, 14 Sep 2001 12:04:02 -0400 From: Thomas Narten Subject: [dhcwg] FWD: Re: New mDNS configuration language Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Are folks on the dhcwg list following ths mDNS thread on namedroppers? There are discussions on rfc2937 that I think folks here could contribute to. Thomas ------- Forwarded Message From: Bernard Aboba To: Aidan Williams cc: namedroppers@ops.ietf.org Date: Thu, 13 Sep 2001 22:18:01 -0700 (PDT) Subject: Re: New mDNS configuration language > > mDNS enable/disable option can support multiple scopes, no? > > > > Yes, but not in this way: > mdns-link-local, netbios, mdns-site-local, isp-dns Yes, RFC 2937 can provide the *order* in which the services are used. > I view mdns-enable as an additional search-list proposal, to a large > extent overlapping rfc2937, and without the ability to interleave > different mdns multicast scopes with other name services (as above). > Not sure I agree with that. mdns-enable doesn't overlap with RFC 2937, since that document isn't clear about enable/disable semantics. > Maybe the real problem is that nobody wants to (or has) implemented > the host support for rfc2937 as is. Is that true? No implementations at all? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. ------- End of Forwarded Message _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 14 12:56:59 2001 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 MAA21824; Fri, 14 Sep 2001 12:56:54 -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 MAA04741; Fri, 14 Sep 2001 12:47:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04713 for ; Fri, 14 Sep 2001 12:47:56 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21701 for ; Fri, 14 Sep 2001 12:48:23 -0400 (EDT) From: Jack_Fijolek@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f8EGimg21609; Fri, 14 Sep 2001 09:44:48 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f8EGlNu10095; Fri, 14 Sep 2001 09:47:23 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256AC7.005C3544 ; Fri, 14 Sep 2001 09:47:09 -0700 X-Lotus-FromDomain: 3COM To: "Biswaroop Mukherjee" cc: "Yu (Ryan) Chen" , dhcwg Message-ID: <88256AC7.005C322C.00@hqoutbound.ops.3com.com> Date: Fri, 14 Sep 2001 11:49:44 -0500 Subject: RE: [dhcwg] dhcp-aaa Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Roop, Is this draft currently active or being discussed. I am confused about the conflicting February and May dates? Thanks, Jack "Biswaroop Mukherjee" on 09/14/2001 10:20:18 AM Sent by: "Biswaroop Mukherjee" To: "Yu Chen" , dhcwg cc: (Jack Fijolek/MW/US/3Com) Subject: RE: [dhcwg] dhcp-aaa Check out "Extensions to DHCP for Roaming Users ". http://search.ietf.org/internet-drafts/draft-ietf-dhc-dhcproam-00.txt -- Roop ___________________________________________________________ The contents of this email are Nortel Networks Confidential > -----Original Message----- > From: Yu (Ryan) Chen [mailto:yrchen@agere.com] > Sent: Friday, September 14, 2001 10:40 AM > To: dhcwg > Subject: [dhcwg] dhcp-aaa > > > Hi, can anyone tell me where I can find > detail protocol of interaction between DHCP and AAA. > Is that a complete work or in progress? > The internet draft I found only have abstract description. > > Thanks, > Ryan > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 14 15:07:17 2001 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 PAA24751; Fri, 14 Sep 2001 15:07:17 -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 PAA08840; Fri, 14 Sep 2001 15:06:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08821 for ; Fri, 14 Sep 2001 15:06:05 -0400 (EDT) Received: from 3miasto.net (root@3miasto.net [217.96.12.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24740 for ; Fri, 14 Sep 2001 15:06:14 -0400 (EDT) Received: from scope (pc64.gdynia.sdi.tpnet.pl [213.77.131.64]) by 3miasto.net (8.11.6/8.11.0) with ESMTP id f8EJ5hZ06055 for ; Fri, 14 Sep 2001 21:05:43 +0200 Date: Fri, 14 Sep 2001 21:05:10 +0200 From: Artur Guja X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: Artur Guja X-Priority: 3 (Normal) Message-ID: <164937414.20010914210510@3miasto.net> To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Clarification necessary Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hello listees, There are several points in the DHCPv6 draft than I feel need clarification in further drafts. I understand that some of it may seem clear to you, some of it may have already been discussed. Nevertheless I would appreciate maybe just a little note on EACH of htese points. 1) Does the server include DUID option in ADVERTISE or REPLY? 2) Should the client save its leases to a file or do they just go to the memory? IOW, are they lost upon reboot? 3) What is the server's reply to a DECLINE? Is there none, or is it a REPLY message? What is in such a REPLY? (New leases or empty IAs???) 4) Why should there be more than one address assigned to an IA? If so, how can a client indicate it wants more than one address? (The IAs have to be empty in SOLICIT). I'm currently working on an actual implemtation of DHCPv6 for my diploma at the TUG (Technical Univ of Gdansk). I'd appreciate any help. Thanks in advance, Artur G. PS: The best help would be to get DHCPv6 to a FINAL standard ASAP, so that I could be sure what to write :)))) _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 14 17:00:00 2001 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 QAA26389; Fri, 14 Sep 2001 16:59:56 -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 QAA11359; Fri, 14 Sep 2001 16:56:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11334 for ; Fri, 14 Sep 2001 16:56:54 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26359 for ; Fri, 14 Sep 2001 16:57:21 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f8EKuOQ08316 for ; Fri, 14 Sep 2001 15:56:24 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8EKuN319192 for ; Fri, 14 Sep 2001 15:56:23 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Fri Sep 14 15:56:22 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Sep 2001 15:56:22 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B35C5@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Artur Guja'" , dhcwg@ietf.org Subject: RE: [dhcwg] Clarification necessary Date: Fri, 14 Sep 2001 15:56:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13D5F.B4E04A70" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13D5F.B4E04A70 Content-Type: text/plain; charset="iso-8859-1" Some of these points were ones I was going to raise. We do need to work out some of the message contents (options) a bit more completely. Let me try to answer what I think we should do in these situations (prefixed by BV>). See below. - Bernie Volz -----Original Message----- From: Artur Guja [mailto:skybird@3miasto.net] Sent: Friday, September 14, 2001 3:05 PM To: dhcwg@ietf.org Subject: [dhcwg] Clarification necessary Hello listees, There are several points in the DHCPv6 draft than I feel need clarification in further drafts. I understand that some of it may seem clear to you, some of it may have already been discussed. Nevertheless I would appreciate maybe just a little note on EACH of htese points. 1) Does the server include DUID option in ADVERTISE or REPLY? BV> Yes, I think it should include the DUID. Basically, just as the BV> client MUST send the DUID in all messages, so must the server in BV> all "replies". 2) Should the client save its leases to a file or do they just go to the memory? IOW, are they lost upon reboot? BV> A client SHOULD save them such that they survive reboots. This BV> is what many DHCPv4 clients already do so it really shouldn't be BV> such a big deal. Some of the revised text we're working on will BV> provide more clarification around this in cases where a client BV> has no permanent storage capabilities. Basically, an ADVERTISE BV> will be able to include other IAs for the client that the server BV> knows about and it is recommended that these types of clients BV> always use the same IA ID (such as 0). 3) What is the server's reply to a DECLINE? Is there none, or is it a REPLY message? What is in such a REPLY? (New leases or empty IAs???) BV> This is one of the areas that I think needs further clarification. BV> This is also more complicated because there could be some kinds of BV> errors that need to be reported (either for a specific address or BV> for an IAID - and there could be multiple of both in a Decline). BV> I would suggest the server send back an IA ID with no addresses BV> if the request is accepted. If errors occur, the addresses that BV> failed would need to be included. BV> BV> There are more interesting issues as well, such as what about the BV> T1/T2 times - I would suggest that those are ignored by the client BV> for a reply to a Decline (or Release). BV> BV> One other thought ... we could have the server return IAIDs and BV> the addresses that were released with 0 lifetimes! 4) Why should there be more than one address assigned to an IA? If so, how can a client indicate it wants more than one address? (The IAs have to be empty in SOLICIT). BV> I'm not going to get into the more than one address per IA issue BV> for now (that's been discussed and rehashed enough times). I believe BV> the text for Solicit is wrong and will be correct - the information BV> received in the Advertise for the IA should be included (that helps BV> the server to remember what it Advertised to the client). The client BV> can NOT ask for a particular number of addresses. It can ask for BV> addresses. It gets what it gets. If it wants more, it must ask for BV> "more" by using a new IAID. If it gets more than it wants, it can BV> keep them or Release those addresses. I'm currently working on an actual implemtation of DHCPv6 for my diploma at the TUG (Technical Univ of Gdansk). I'd appreciate any help. Thanks in advance, Artur G. PS: The best help would be to get DHCPv6 to a FINAL standard ASAP, so that I could be sure what to write :)))) BV> We're working on it! _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C13D5F.B4E04A70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Clarification necessary

Some of these points were ones I was going to raise. = We do need to work out some of the message contents (options) a bit = more completely.

Let me try to answer what I think we should do in = these situations (prefixed by BV>). See below.

- Bernie Volz

-----Original Message-----
From: Artur Guja [mailto:skybird@3miasto.net]
Sent: Friday, September 14, 2001 3:05 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Clarification necessary


Hello listees,

There are several points in the DHCPv6 draft than I = feel need
clarification in further drafts.
I understand that some of it may seem clear to you, = some of it may
have already been discussed. Nevertheless I would = appreciate maybe
just a little note on EACH of htese points.

1) Does the server include DUID option in ADVERTISE = or REPLY?

BV> Yes, I think it should include the DUID. = Basically, just as the
BV> client MUST send the DUID in all messages, so = must the server in
BV> all "replies".

2) Should the client save its leases to a file or do = they just go to
the memory? IOW, are they lost upon reboot?

BV> A client SHOULD save them such that they = survive reboots. This
BV> is what many DHCPv4 clients already do so it = really shouldn't be
BV> such a big deal. Some of the revised text = we're working on will
BV> provide more clarification around this in = cases where a client
BV> has no permanent storage capabilities. = Basically, an ADVERTISE
BV> will be able to include other IAs for the = client that the server
BV> knows about and it is recommended that these = types of clients
BV> always use the same IA ID (such as 0).

3) What is the server's reply to a DECLINE? Is there = none, or is it a
REPLY message? What is in such a REPLY? (New leases = or empty IAs???)

BV> This is one of the areas that I think needs = further clarification.
BV> This is also more complicated because there = could be some kinds of
BV> errors that need to be reported (either for a = specific address or
BV> for an IAID - and there could be multiple of = both in a Decline).
BV> I would suggest the server send back an IA ID = with no addresses
BV> if the request is accepted. If errors occur, = the addresses that
BV> failed would need to be included.
BV>
BV> There are more interesting issues as well, = such as what about the
BV> T1/T2 times - I would suggest that those are = ignored by the client
BV> for a reply to a Decline (or Release). =
BV>
BV> One other thought ... we could have the = server return IAIDs and
BV> the addresses that were released with 0 = lifetimes!

4) Why should there be more than one address assigned = to an IA? If so,
how can a client indicate it wants more than one = address? (The IAs
have to be empty in SOLICIT).

BV> I'm not going to get into the more than one = address per IA issue
BV> for now (that's been discussed and rehashed = enough times). I believe
BV> the text for Solicit is wrong and will be = correct - the information
BV> received in the Advertise for the IA should = be included (that helps
BV> the server to remember what it Advertised to = the client). The client
BV> can NOT ask for a particular number of = addresses. It can ask for
BV> addresses. It gets what it gets. If it wants = more, it must ask for
BV> "more" by using a new IAID. If it = gets more than it wants, it can
BV> keep them or Release those addresses.

I'm currently working on an actual implemtation of = DHCPv6 for my
diploma at the TUG (Technical Univ of Gdansk). I'd = appreciate any
help.

Thanks in advance,
Artur G.

PS: The best help would be to get DHCPv6 to a FINAL = standard ASAP, so
that I could be sure what to write :))))

BV> We're working on it!


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

------_=_NextPart_001_01C13D5F.B4E04A70-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 17 09:51:39 2001 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 JAA12511; Mon, 17 Sep 2001 09:51:34 -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 JAA00520; Mon, 17 Sep 2001 09:46:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00489 for ; Mon, 17 Sep 2001 09:46:11 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12419 for ; Mon, 17 Sep 2001 09:46:08 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA28520 for ; Mon, 17 Sep 2001 09:44:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20010917094320.00b4dc08@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Sep 2001 09:44:32 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Revised updates for transmisssion and retransmission Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Here is the text for transmission and retransmission, based on Bernies's feedback. I copied come of Bernie's comments back into this text, along with my responses and edited text. Several of Bernie's comments referred to issues that will be addressed by or otherwise depends on the text being generated for IAs. Additional changes to this text will be made once the text for IAs has been finalized. - Ralph 7.5. Configuration Variables This section presents a table of client and server configuration variables and the default or initial values for these variables. BV> Didn't we want to drop this retransmission parameter option BV> since it opens up many cans of worms as per the San Diego IETF? RD> Dropped sentence: "The client-specific variables MAY be configured RD> on the server and MAY be delivered to the client through the "DHCP RD> Retransmission Parameter Option" in a Reply message. Parameter Default Description ------------------------------------- MIN_SOL_DELAY 1 MIN (secs) to delay 1st mesg MAX_SOL_DELAY 5 MAX (secs) to delay 1st mesg ADV_TIMEOUT 500 SOL Retrans timer (msecs) ADV_MAX_RT 30 MAX timer value (secs) SOL_MAX_ATTEMPTS 0 MAX attempts (0 = infinite) REP_TIMEOUT 250 Retrans timer (msecs) for Reply REP_MAX_RT 0 MAX Retrans time (0 = infinite) REQ_MAX_ATTEMPTS 10 MAX Request/Confirm/Renew/Rebind attempts REL_MSG_ATTEMPTS 5 MAX Release/Decline attempts SRVR_PREF_WAIT 2 Advertise Collect timer (secs) 13. Reliability of Client Initiated Message Exchanges DHCP clients are responsible for reliable delivery of messages in the client-initiated message exchanges described in sections 14 and 15. If a DHCP client fails to receive an expected response from a server, the client must retransmit its message. This section describes the retransmission strategy to be used by clients in client-initiated message exchanges. The client begins the message exchange by transmitting a message to the server. The message exchange terminates when either the client successfully receives the appropriate response or responses from a server or servers, or when the message exchange is considered to have failed according to the retransmission mechanism described below. The client retransmission behavior is controlled and describe by five variables: RT Retransmission timeout IRT Initial retransmission time MRC Maximum retransmission count MRT Maximum retransmission time MRD Maximum retransmission duration RAND Randomization factor With each message transmission or retransmission, the client sets RT according to the rules given below. If RT expires before the message exchange terminates, the client recomputes RT and retransmits the message. Each of the computations of a new RT include a randomization factor (RAND), which is a random number chosen with a uniform distribution between -0.1 and +0.1. The randomization factor is included to minimize synchronization of messages transmitted by DHCP clients. The algorithm for choosing a random number does not need to be cryptographically sound. The algorithm SHOULD produce a different sequence of numbers from each invocation of the DHCP client. RT for the first message transmission is based on IRT: RT = IRT + RAND*IRT RT for each subsequent message transmission is based on the previous value of RT: RT = RTprev + RAND*RTprev MRT specifies an upper bound on the value of RT. If MRT has a value of 0, there is no upper limit on the value of RT. Otherwise: if (RT > MRT) RT = MRT + RAND*MRT MRC specifies an upper bound on the number of times a client may retransmit a message. If MRC has a value of 0, the client MUST continue to retransmit the original message until a response is received. Otherwise, the message exchange fails if the client attempts to transmit the original message more than MRC times. MRD specifies an upper bound on the length of time a client may retransmit a message. If MRD has a value of 0, the client MUST continue to retransmit the original message until a response is received. Otherwise, the message exchange fails if the client attempts to transmit the original message more than MRD seconds. BV> Just to be clear, might be good to say that EITHER or BOTH of BV> MRC or MRD can stop retransmissions? In most cases it appears BV> that only one is active, but it is always possible that both BV> could be. RD> Added following paragraph. If both MRC and MRD are non-zero, the message exchange fails whenever either of the conditions specified in the previous paragraph are met. 14. DHCP Server Solicitation This section describes how a client locates servers. The behavior of client and server implementations is discussed, along with the messages they use. [...] 14.3. Client Behavior A client uses the Solicit message to discover DHCP servers configured to serve addresses on the link to which the client is attached. BV> While probably not something that is needed in this section, we BV> really don't have much text to describe the "transaction-ID". All BV> we generally say is to "generate a transaction ID". However, we BV> should make it clear to clients that they should attempt to BV> generate "unique" transaction ids. Unique here is best if it is BV> over a long period of time, but it must be longer than any cache BV> times in servers. Probably the best rule of thumb is for clients BV> to use to generate this number by incrementing it. Then the only BV> issue is what to set it to when (re)booting - especially if there BV> is no means to remember the last used number. RD> Added section 14.3.1 14.3.1. Use of Transaction-ID field The "transaction-ID" field holds a value used by clients and servers to synchronize server responses to client messages. A client SHOULD choose a different transaction-ID for each new message it sends. A client MUST leave the transaction-ID unchanged in retransmissions of messages. 14.3.2. Creation of Solicit messages The client sets the "msg-type" field to SOLICIT. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client includes a DUID option to identify itself to the server. The client MUST include options for any IAs to which it wants the server to assign addresses. The client may include addresses in the IAs as a hint to the server about addresses for which the client may have a preference. The client MAY include an Option Request Option in the Solicit message. The client MUST NOT include any other options except those specifically allowed as defined by specific options. 14.3.3. Transmission of Solicit Messages The client sends the Solicit message to the All_DHCP_Agents multicast address. The client MUST use an address assigned to the interface for which the client is interested in obtaining configuration information as the source address in the IP header of the datagram carrying the Rebind message, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client's first Solicit message on the interface MUST be delayed by a random amount of time between MIN_SOL_DELAY and MAX_SOL_DELAY. This random delay desynchronizes clients which start at the same time (e.g., after a power outage). The client transmits the message according to section 13, using the following parameters: IRT ADV_TIMEOUT MRC 0 MRT ADV_MAX_RT MRD 0 The mechanism in section 13 is modified as follows for use in the transmission of Solicit messages. The message exchange is not terminated by the receipt of an Advertise before ADV_TIMEOUT has BV> ADV_MSG_TIMEOUT doesn't exist. I think you renamed it to BV> ADV_TIMEOUT? ADV_MSG_TIMEOUT is used many times. RD> Fixed all references to ADV_MSG_TIMEOUT elapsed. Rather, the client collects Advertise messages until ADV_TIMEOUT has elapsed. The first RT MUST be selected to be strictly greater than ADV_TIMEOUT by choosing RAND to be strictly greater than 0. BV> Did you mean MRD, not MRT? MRT limits the time of a single BV> retransmission. Also, the "If the DHCP client is otherwise configured" BV> made me re-read the paragraph several times. Perhaps there is a better BV> way to state this? "If the DHCP client is configured with a non-zero BV> MRC or MRD, ...". BV> Oh, might you want to say "SOL_MAX_ATTEMPTS" instead of MRC? RD> Edited text in following paragraph to A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client is configured with either MRC or MRD set to a value other than 0, it MUST stop trying to configure the interface if the message exchange fails. After the DHCP client stops trying to configure the interface, it MAY choose to restart the reconfiguration process after some external event, such as user input, system restart, or when the client is attached to a new link. 14.3.4. Receipt of Advertise messages BV> Also, this Retransmit logic is a bit weird beause of SRVR_PREF_WAIT. BV> Does it make sense to state something like "A client only retransmits BV> a Solicit if it fails to receive any Advertises before the retransmission BV> timer expires. If a client receives one or more Advertise messages, it BV> then must wait SRVR_PREF_WAIT seconds from the time of the transmit BV> for any additional Advertise messages before proceeding." RD> Edited following paragraph A client only retransmits a Solicit message if it does not receive an Advertise within SRVR_PREF_WAIT seconds after sending a Solicit message. A client MUST collect Advertise messages for SRVR_PREF_WAIT seconds, unless it receives an Advertise message with a preference value of 255. The preference value is carried in the Preference option (section 19.5). Any Solicit that does not include a Preference option is considered to have a preference value of 0. If the client receives an Advertise message with a preference value of 255, then the client MAY act immediately on that Advertise message without waiting for any more additional Advertise messages. Upon receipt of one or more validated Advertise messages, the client selects one or more Advertise messages based upon the following criteria. - Those Advertise messages with the highest server preference value are preferred over all other Advertise messages. - Within a group of Advertise messages with the same server preference value, a client MAY select those servers whose Advertise messages advertise information of interest to the client. For example, the client may choose a server that returned an advertisement with configuration options of interest to the client. Once a client has selected Advertise message(s), the client will typically store information about each server, such as server preference value, addresses advertised, when the advertisement was received, and so on. Depending on the requirements of the client's invoking user, the client MAY initiate a configuration exchange with the server(s) immediately, or MAY defer this exchange until later. If the client needs to select an alternate server in the case that a chosen server does not respond, the client chooses the server with the next highest preference value. The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available addresses advertised in IAs. [...] 15. DHCP Client-Initiated Configuration Exchange [...] 15.3. Client Behavior [...] 15.3.1. Creation and transmission of Request messages If the client is using stateful address configuration and needs either an initial set of addresses or additional addresses, it MUST send a Request message to obtain new addresses and other configuration information. The client includes one or more IAs in the Request message, to which the server assigns new addresses. The server then returns IA(s) to the client in a Reply message. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client places the address of the destination server in the "server-address" field. The client adds a DUID option to identify itself to the server. The client adds any other appropriate options, including one or more IA options (if the client is requesting that the server assign it some network addresses). The list of addresses in each included IA MUST be empty. If the client is not requesting that the server assign it any addresses, the client omits the IA option. If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Request message to the server. Otherwise, the client sends the Request message to the All_DHCP_Agents multicast address. The client MUST use an address assigned to the interface for which the client is interested in obtaining configuration information as the source address in the IP header of the datagram carrying the Rebind message, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REQ_MAX_ATTEMPTS MRT REP_MAX_RT MRD 0 If the message exchange fails, the client MAY choose one of the following actions: - Select another server from a list of servers known to the client; e. g., servers that responded with an Advertise message - Initiate the server discovery described in section 14 - Terminate the configuration process and report failure 15.3.2. Creation and transmission of Confirm messages Whenever a client may have moved to a new link, its IPv6 addresses and other configuration information may no longer be valid. Examples of times when a client may have moved to a new link include: o The client reboots o The client is physically disconnected from a wired connection o The client returns from sleep mode o The client using a wireless technology changes cells In any situation when a client may have moved to a new link, the client MUST initiate a Confirm/Reply message exchange. The client includes any IAs, along with the addresses associated with those IAs, in its Confirm message. Any responding servers will indicate the acceptability of the addresses with the status in the IA it returns to the client. The client sets the "msg-type" field to CONFIRM. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client sets the "server-address" field to 0. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options (if the client is requesting that the server confirm the validity of some network addresses). If the client does include any IA options, it MUST include the list of addresses the client currently has associated with that IA. The client MUST use an address assigned to the interface for which the client is interested in obtaining configuration information as the source address in the IP header of the datagram carrying the Rebind message, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REQ_MSG_ATTEMPTS MRT REP_MAX_RT MRD 0 If the message exchange fails, the client MUST restart the configuration process by locating a DHCP server as described in section 14. The client SHOULD report the failure of the configuration process to the application layer. 15.3.3. Creation and transmission of Renew messages IPv6 addresses assigned to a client through an IA use the same preferred and valid lifetimes as IPv6 addresses obtained through stateless autoconfiguration. The server assigns preferred and valid lifetimes to the IPv6 addresses it assigns to an IA. To extend those lifetimes, the client sends a Renew message to the server containing an "IA option" for the IA and its associated addresses. The server determines new lifetimes for the addresses in the IA according to the server's administrative configuration. The server may also add new addresses to the IA. The server may remove addresses from the IA by setting the preferred and valid lifetimes of those addresses to zero. The server controls the time at which the client contacts the server to extend the lifetimes on assigned addresses through the T1 and T2 parameters assigned to an IA. If the server does not assign an explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the shortest preferred lifetime of any address assigned to the IA and T2 defaults to 0.875 times the shortest preferred lifetime of any address assigned to the IA. At time T1 for an IA, the client initiates a Request/Reply message exchange to extend the lifetimes on any addresses in the IA. The client includes an IA option with all addresses currently assigned to the IA in its Request message. The client sets the "msg-type" field to RENEW. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client places the address of the destination server in the "server-address" field. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options (if the client is requesting that the server extend the lease on some IAs; note that the client may check the status of other configuration parameters without asking for lease extensions). If the client does include any IA options, it MUST include the list of addresses the client currently has associated with that IA. If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Renew message to the server. Otherwise, the client sends the Renew message to the All_DHCP_Agents multicast address. The client MUST use an address assigned to the interface for which the client is interested in obtaining configuration information as the source address in the IP header of the datagram carrying the Rebind message, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC 0 MRT REP_MAX_RT MRD 0 The mechanism in section 13 is modified as follows for use in the transmission of Renew messages. The message exchange is terminated when time T2 is reached (see section 15.3.4), at which time the client begins a Rebind message exchange. 15.3.4. Creation and transmission of Rebind messages At time T2 for an IA (which will only be reached if the server to which the Renew message was sent at time T1 has not responded), the client initiates a Rebind/Reply message exchange. The client includes an IA option with all addresses currently assigned to the IA in its Rebind message. The client sends this message to the All_DHCP_Agents multicast address. The client sets the "msg-type" field to REBIND. The client generates a transaction ID inserts this value in the "transaction-ID" field. The client sets the "server-address" field to 0. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options. If the client does include any IA options (if the client is requesting that the server extend the lease on some IAs; note that the client may check the status of other configuration parameters without asking for lease extensions), it MUST include the list of addresses the client currently has associated with that IA. The client MUST use an address assigned to the interface for which the client is interested in obtaining configuration information as the source address in the IP header of the datagram carrying the Rebind message, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC 0 MRT REP_MAX_RT MRD 0 The mechanism in section 13 is modified as follows for use in the transmission of Renew messages. The message exchange is terminated when the lease for the IA expires (see section 11), at which time the client has several alternative actions to choose from: - When the lease on the IA expires, the client may choose to use a Solicit message to locate a new DHCP server and send a Request for the expired IA to the new server - Some addresses in the IA may have lifetimes that extend beyond the lease of the IA, so the client may choose to continue to use those addresses; once all of the addresses have expired, the client may choose to locate a new DHCP server - The client may have other addresses in other IAs, so the client may choose to discard the expired IA and use the addresses in the other IAs 15.3.5. Receipt of Reply message in response to a Request, Confirm, Renew or Rebind message [...] 15.3.6. Creation and transmission of Release messages The client sets the "msg-type" field to RELEASE. The client generates a transaction ID and places this value in the "transaction-ID" field. The client places the IP address of the server that allocated the address(es) in the "server-address" field. The client adds a DUID option to identify itself to the server. The client includes options containing the IAs it is releasing in the "options" field. The addresses to be released MUST be included in the IAs. The appropriate "status" field in the options MUST be set to indicate the reason for the release. The client MUST NOT use any of the addresses in the IAs in the message as the source address in the Release message or in any subsequently transmitted message. If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Release message to the server. Otherwise, the client sends the Release message to the All_DHCP_Agents multicast address. The client MUST use an address for the interface to which the IAs in the Release message are assigned as the source address for the Release message, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. A client MAY choose to wait for a Reply message from the server in response to the Release message. If the client does wait for a Reply, the client MAY choose to retransmit the Release message. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REL_MSG_ATTEMPTS MRT REP_MAX_RT MRD 0 The client MUST abandon the attempt to release addresses if the Release message exchange fails. The client MUST stop using all of the addresses in the IA(s) being released as soon as the client begins the Release message exchange process. If an IA is released but the Reply from a DHCP server is lost, the client will retransmit the Release message, and the server may respond with a Reply indicating a status of "Nobinding". Therefore, the client does not treat a Reply message with a status of "Nobinding" in a Release message exchange as if it indicates an error. Note that if the client fails to release the IA, the addresses assigned to the IA will be reclaimed by the server when the lease associated with it expires. 15.3.7. Receipt of Reply message in response to a Release message Upon receipt of a valid Reply message, the client can consider the Release event successful, and SHOULD return the successful status to the application layer, if an application initiated the release. 15.3.8. Creation and transmission of Decline messages The client sets the "msg-type" field to DECLINE. The client generates a transaction ID and places this value in the "transaction-ID" field. The client places the IP address of the server that allocated the address(es) in the "server-address" field. The client adds a DUID option to identify itself to the server. The client includes options containing the IAs it is declining in the "options" field. The addresses to be released MUST be included in the IAs. The appropriate "status" field in the options MUST be set to indicate the reason for declining the address. The client MUST NOT use any of the addresses in the IAs in the message as the source address in the Decline message or in any subsequently transmitted message. If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Decline message to the server. Otherwise, the client sends the Decline message to the All_DHCP_Agents multicast address. The client MUST use an address for the interface to which the IAs in the Release message are assigned as the source address for the Decline message, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. The client transmits the message according to section 13, using the following parameters: IRT REP_TIMEOUT MRC REL_ATTEMPTS MRT REP_MAX_RT MRD 0 The client MUST abandon the attempt to decline addresses if the Decline message exchange fails. 15.3.9. Receipt of Reply message in response to a Decline message Upon receipt of a valid Reply message, the client can consider the Decline event successful. [...] _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 17 15:30:38 2001 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 PAA18784; Mon, 17 Sep 2001 15:30:34 -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 PAA11642; Mon, 17 Sep 2001 15:25:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11618 for ; Mon, 17 Sep 2001 15:25:26 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18734 for ; Mon, 17 Sep 2001 15:25:24 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.208.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01690; Mon, 17 Sep 2001 13:24:33 -0600 (MDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8HJOYr01094; Mon, 17 Sep 2001 21:24:34 +0200 (MET DST) Date: Mon, 17 Sep 2001 21:20:23 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [dhcwg] Clarification necessary To: "Bernie Volz (EUD)" Cc: "'Artur Guja'" , dhcwg@ietf.org In-Reply-To: "Your message with ID" <66F66129A77AD411B76200508B65AC697B35C5@eambunt705.ena-east.ericsson.se> Message-ID: 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: X-BeenThere: dhcwg@ietf.org > 2) Should the client save its leases to a file or do they just go to > the memory? IOW, are they lost upon reboot? > > BV> A client SHOULD save them such that they survive reboots. This > BV> is what many DHCPv4 clients already do so it really shouldn't be > BV> such a big deal. Some of the revised text we're working on will > BV> provide more clarification around this in cases where a client > BV> has no permanent storage capabilities. Basically, an ADVERTISE > BV> will be able to include other IAs for the client that the server > BV> knows about and it is recommended that these types of clients > BV> always use the same IA ID (such as 0). Hmm, has there been any discussion what impact this will have on reconfigure to do renumbering? I guess the same issue appears with DHCPv4 and its new ability to do reconfigure. At a minimum it might make sense to document that reconfigure might not be able to reach nodes that are turned off but that those nodes might retain the leases in stable storage. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 17 16:04:14 2001 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 QAA20583; Mon, 17 Sep 2001 16:04:14 -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 PAA12365; Mon, 17 Sep 2001 15:51:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12341 for ; Mon, 17 Sep 2001 15:51:08 -0400 (EDT) Received: from 3miasto.net (root@3miasto.net [217.96.12.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20196 for ; Mon, 17 Sep 2001 15:51:03 -0400 (EDT) Received: from scope (pc64.gdynia.sdi.tpnet.pl [213.77.131.64]) by 3miasto.net (8.11.6/8.11.0) with ESMTP id f8HJoOh23146; Mon, 17 Sep 2001 21:50:25 +0200 Date: Mon, 17 Sep 2001 21:49:56 +0200 From: Artur Guja X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: Artur Guja X-Priority: 3 (Normal) Message-ID: <19973407.20010917214956@3miasto.net> To: "dhcwg@ietf.org" , Erik Nordmark Subject: Re[2]: [dhcwg] Clarification necessary In-reply-To: References: 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: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit EN> At a minimum it might make sense to document that reconfigure might not EN> be able to reach nodes that are turned off but that those nodes EN> might retain the leases in stable storage. EN> Erik In such a case, I believe, the client is required to send a CONFIRM message to, well, confirm the leases. The server can then reply with the lifetimes set to 0, indicating expired leases. Or it can reply with a RECONFIGURE message. Or maybe both :))) Artur G. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 17 18:11:36 2001 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 SAA22765; Mon, 17 Sep 2001 18:11:36 -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 SAA17724; Mon, 17 Sep 2001 18:06:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17701 for ; Mon, 17 Sep 2001 18:06:30 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22684 for ; Mon, 17 Sep 2001 18:06:29 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f8HM5HQ18451 for ; Mon, 17 Sep 2001 17:05:17 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8HM5Hl03840 for ; Mon, 17 Sep 2001 17:05:17 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Sep 17 17:05:17 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Sep 2001 17:05:16 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B35E3@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Erik Nordmark'" Cc: "'Artur Guja'" , dhcwg@ietf.org Subject: RE: [dhcwg] Clarification necessary Date: Mon, 17 Sep 2001 17:05:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13FC4.D398C930" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13FC4.D398C930 Content-Type: text/plain; charset="iso-8859-1" Hi: As Artur already mentioned, when a node restarts it would likely assume it is perhaps no longer connected to the same link and take steps to "confirm" its addresses by multicasting the Confirm message. Server(s) will respond to this with an indication that the addresses are unacceptable (likely based on the prefixes) or acceptable (again based on the prefixes or because the server assigned those addresses). There may be several different levels of indications in each case - since a server that didn't assign the address might only be able to base its response on the prefixes and not the actual addresses. A server that receives the Confirm and has a (perhaps "timed-out") Reconfigure-Init needed flag for that client (based on DUID) SHOULD then take steps to initiate the Reconfigure-Init. My own personal view is that Confirm should not be used to assign new addresses or adjust lifetimes (or even T1/T2 renewal times). It should simply be used to confirm the validity of the addresses on that link. But I'm not sure that is WG consensus. - Bernie Volz -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] Sent: Monday, September 17, 2001 3:20 PM To: Bernie Volz (EUD) Cc: 'Artur Guja'; dhcwg@ietf.org Subject: RE: [dhcwg] Clarification necessary > 2) Should the client save its leases to a file or do they just go to > the memory? IOW, are they lost upon reboot? > > BV> A client SHOULD save them such that they survive reboots. This > BV> is what many DHCPv4 clients already do so it really shouldn't be > BV> such a big deal. Some of the revised text we're working on will > BV> provide more clarification around this in cases where a client > BV> has no permanent storage capabilities. Basically, an ADVERTISE > BV> will be able to include other IAs for the client that the server > BV> knows about and it is recommended that these types of clients > BV> always use the same IA ID (such as 0). Hmm, has there been any discussion what impact this will have on reconfigure to do renumbering? I guess the same issue appears with DHCPv4 and its new ability to do reconfigure. At a minimum it might make sense to document that reconfigure might not be able to reach nodes that are turned off but that those nodes might retain the leases in stable storage. Erik ------_=_NextPart_001_01C13FC4.D398C930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Clarification necessary

Hi:

As Artur already mentioned, when a node restarts it = would likely assume it is perhaps no longer connected to the same link = and take steps to "confirm" its addresses by multicasting the = Confirm message. Server(s) will respond to this with an indication that = the addresses are unacceptable (likely based on the prefixes) or = acceptable (again based on the prefixes or because the server assigned = those addresses). There may be several different levels of indications = in each case - since a server that didn't assign the address might only = be able to base its response on the prefixes and not the actual = addresses.

A server that receives the Confirm and has a (perhaps = "timed-out") Reconfigure-Init needed flag for that client = (based on DUID) SHOULD then take steps to initiate the = Reconfigure-Init.

My own personal view is that Confirm should not be = used to assign new addresses or adjust lifetimes (or even T1/T2 renewal = times). It should simply be used to confirm the validity of the = addresses on that link. But I'm not sure that is WG = consensus.

- Bernie Volz

-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.c= om]
Sent: Monday, September 17, 2001 3:20 PM
To: Bernie Volz (EUD)
Cc: 'Artur Guja'; dhcwg@ietf.org
Subject: RE: [dhcwg] Clarification necessary



> 2) Should the client save its leases to a file = or do they just go to
> the memory? IOW, are they lost upon = reboot?
>
> BV> A client SHOULD save them such that they = survive reboots. This
> BV> is what many DHCPv4 clients already do = so it really shouldn't be
> BV> such a big deal. Some of the revised = text we're working on will
> BV> provide more clarification around this = in cases where a client
> BV> has no permanent storage capabilities. = Basically, an ADVERTISE
> BV> will be able to include other IAs for = the client that the server
> BV> knows about and it is recommended that = these types of clients
> BV> always use the same IA ID (such as = 0).

Hmm, has there been any discussion what impact this = will have on reconfigure
to do renumbering? I guess the same issue appears = with DHCPv4 and its
new ability to do reconfigure.

At a minimum it might make sense to document that = reconfigure might not
be able to reach nodes that are turned off but that = those nodes
might retain the leases in stable storage.

  Erik

------_=_NextPart_001_01C13FC4.D398C930-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 18 15:41:13 2001 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 PAA00602; Tue, 18 Sep 2001 15:41:13 -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 PAA29566; Tue, 18 Sep 2001 15:34:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29546 for ; Tue, 18 Sep 2001 15:34:10 -0400 (EDT) Received: from 3miasto.net (root@3miasto.net [217.96.12.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00391 for ; Tue, 18 Sep 2001 15:34:05 -0400 (EDT) Received: from SCOPE (pc64.gdynia.sdi.tpnet.pl [213.77.131.64]) by 3miasto.net (8.11.6/8.11.0) with ESMTP id f8IJXMh17587 for ; Tue, 18 Sep 2001 21:33:22 +0200 Date: Tue, 18 Sep 2001 21:32:54 +0200 From: "Guja, ArturX" X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: "Guja, ArturX" X-Priority: 3 (Normal) Message-ID: <173693552.20010918213254@3miasto.net> To: dhcwg@ietf.org X-Sender: Artur Guja Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Interface Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Sorry for posting so many questions, but I'm working overtime on my diploma here. I'm really grateful for any input. So another one: Is the client required to send DHCPv6 messages through the interface it is going to configure, or can it send them through any interface? I mean, why should there be such a restriction? After all, it sends the DUID and the link-local address in the message. It might as well use ANY interface for communication with the server, eg. when it is multi-homed, and there is a DHCP server available on only one link, but it serves the whole net :))) I know it was mentioned somewhere, but I can't find it. :))) Soory to bother you :))) Artur _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 18 15:53:12 2001 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 PAA00911; Tue, 18 Sep 2001 15:53:12 -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 PAA00033; Tue, 18 Sep 2001 15:52:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00008 for ; Tue, 18 Sep 2001 15:52:23 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00869 for ; Tue, 18 Sep 2001 15:52:14 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f8IJp5Q11869 for ; Tue, 18 Sep 2001 14:51:05 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8IJp4G13854 for ; Tue, 18 Sep 2001 14:51:04 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Sep 18 14:51:01 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Sep 2001 14:51:00 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B35F4@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Guja, ArturX'" , dhcwg@ietf.org Subject: RE: [dhcwg] Interface Date: Tue, 18 Sep 2001 14:50:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1407B.3D6A0D40" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1407B.3D6A0D40 Content-Type: text/plain; charset="iso-8859-1" The client *MUST* send the messages through the interface being configured. The client uses multicast messages and if directly received by the server, that's the way it knows what link the client is on. If a relay receives it and forwards it, that's how it can tag the message having come from that link so that the server knows what link the client is on. If the server doesn't know the correct link, it can't assign the proper addresses. Note however that I feel if a server had told the client it may use unicast and the client has addresses of sufficient scope, there is no reason why the client must use that interface. This requires that client's source address is one of the addresses for that interface that is of "value" to the server in identifying the correct link. For example, a globally unique address would likely be of sufficient scope. - Bernie -----Original Message----- From: Guja, ArturX [mailto:ArturX.Guja@intel.com] Sent: Tuesday, September 18, 2001 3:33 PM To: dhcwg@ietf.org Subject: [dhcwg] Interface Sorry for posting so many questions, but I'm working overtime on my diploma here. I'm really grateful for any input. So another one: Is the client required to send DHCPv6 messages through the interface it is going to configure, or can it send them through any interface? I mean, why should there be such a restriction? After all, it sends the DUID and the link-local address in the message. It might as well use ANY interface for communication with the server, eg. when it is multi-homed, and there is a DHCP server available on only one link, but it serves the whole net :))) I know it was mentioned somewhere, but I can't find it. :))) Soory to bother you :))) Artur _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1407B.3D6A0D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Interface

The client *MUST* send the messages through the = interface being configured. The client uses multicast messages and if = directly received by the server, that's the way it knows what link the = client is on. If a relay receives it and forwards it, that's how it can = tag the message having come from that link so that the server knows = what link the client is on. If the server doesn't know the correct = link, it can't assign the proper addresses.

Note however that I feel if a server had told the = client it may use unicast and the client has addresses of sufficient = scope, there is no reason why the client must use that interface. This = requires that client's source address is one of the addresses for that = interface that is of "value" to the server in identifying the = correct link. For example, a globally unique address would likely be of = sufficient scope.

- Bernie

-----Original Message-----
From: Guja, ArturX [mailto:ArturX.Guja@intel.com]<= /FONT>
Sent: Tuesday, September 18, 2001 3:33 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Interface


Sorry for posting so many questions, but I'm working = overtime on my
diploma here. I'm really grateful for any = input.

So another one:
Is the client required to send DHCPv6 messages = through the interface it is
going to configure, or can it send them through any = interface?
I mean, why should there be such a restriction? = After all, it sends
the DUID and the link-local address in the message. = It might as well
use ANY interface for communication with the server, = eg. when it is
multi-homed, and there is a DHCP server available on = only one link,
but it serves the whole net :)))

I know it was mentioned somewhere, but I can't find = it. :)))
Soory to bother you :)))

Artur



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

------_=_NextPart_001_01C1407B.3D6A0D40-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 19 05:59:14 2001 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 FAA28079; Wed, 19 Sep 2001 05:59:14 -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 FAA00064; Wed, 19 Sep 2001 05:55:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00038 for ; Wed, 19 Sep 2001 05:55:10 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28017 for ; Wed, 19 Sep 2001 05:55:08 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27249; Wed, 19 Sep 2001 03:54:19 -0600 (MDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8J9sNr19359; Wed, 19 Sep 2001 11:54:24 +0200 (MET DST) Date: Wed, 19 Sep 2001 11:50:02 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [dhcwg] Interface To: "Bernie Volz (EUD)" Cc: "'Guja, ArturX'" , dhcwg@ietf.org In-Reply-To: "Your message with ID" <66F66129A77AD411B76200508B65AC697B35F4@eambunt705.ena-east.ericsson.se> Message-ID: 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: X-BeenThere: dhcwg@ietf.org > The client *MUST* send the messages through the interface being configured. > The client uses multicast messages and if directly received by the server, > that's the way it knows what link the client is on. If a relay receives it > and forwards it, that's how it can tag the message having come from that > link so that the server knows what link the client is on. If the server > doesn't know the correct link, it can't assign the proper addresses. Bernie, I suspect that the real constraint is that the client MUST send the message on an interface attached to the same *LINK* as the interface it is trying to configure. When the client has multiple interfaces attached to the same link the server/relay can't tell which one was used (short of inspecting the source MAC address which may or may not differ). If the document will cover this distinction it would make sense to add a reference to draft-ietf-ipngwg-scoping-arch-02.txt. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 19 08:33:55 2001 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 IAA00739; Wed, 19 Sep 2001 08:33:55 -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 IAA03767; Wed, 19 Sep 2001 08:31:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03747 for ; Wed, 19 Sep 2001 08:31:47 -0400 (EDT) Received: from mail.hycomat.co.uk (ns.hycomat.co.uk [194.153.168.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00656 for ; Wed, 19 Sep 2001 08:31:45 -0400 (EDT) From: rme@hycomat.co.uk Received: from rme by mail.hycomat.co.uk with local (Exim 3.15 #1) id 15jfJI-0007cZ-00 for dhcwg@ietf.org; Wed, 19 Sep 2001 11:14:32 +0000 To: dhcwg@ietf.org Date: Wed, 19 Sep 2001 11:14:32 +0000 (UTC) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 isc based prototype Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit hello, I tar'ed my development dir, you can download it from www.hycomat.com/dhcp. Its a dhcpv6 server and client in an early dev. state. Its ISC DHCP v3 based, that means the server can do both. please read the READMEdhcpv6.txt for more details. suggestions welcome ralph meyer _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 19 11:19:20 2001 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 LAA03998; Wed, 19 Sep 2001 11:19:20 -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 LAA08692; Wed, 19 Sep 2001 11:13:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08667 for ; Wed, 19 Sep 2001 11:13:31 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03881 for ; Wed, 19 Sep 2001 11:13:29 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f8JFCo701637 for ; Wed, 19 Sep 2001 10:12:50 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8JFCnx18457 for ; Wed, 19 Sep 2001 10:12:49 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Sep 19 10:12:25 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 10:12:25 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3606@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Erik Nordmark'" Cc: "'Guja, ArturX'" , dhcwg@ietf.org Subject: RE: [dhcwg] Interface Date: Wed, 19 Sep 2001 10:12:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1411D.774433E0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1411D.774433E0 Content-Type: text/plain; charset="iso-8859-1" Erik: Your clarification on the constraint sounds reasonable to me and might well be what is in the draft. I don't recall exactly how it is worded in the draft, so perhaps Ralph will want to make sure we are clear on this. - Bernie -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] Sent: Wednesday, September 19, 2001 5:50 AM To: Bernie Volz (EUD) Cc: 'Guja, ArturX'; dhcwg@ietf.org Subject: RE: [dhcwg] Interface > The client *MUST* send the messages through the interface being configured. > The client uses multicast messages and if directly received by the server, > that's the way it knows what link the client is on. If a relay receives it > and forwards it, that's how it can tag the message having come from that > link so that the server knows what link the client is on. If the server > doesn't know the correct link, it can't assign the proper addresses. Bernie, I suspect that the real constraint is that the client MUST send the message on an interface attached to the same *LINK* as the interface it is trying to configure. When the client has multiple interfaces attached to the same link the server/relay can't tell which one was used (short of inspecting the source MAC address which may or may not differ). If the document will cover this distinction it would make sense to add a reference to draft-ietf-ipngwg-scoping-arch-02.txt. Erik ------_=_NextPart_001_01C1411D.774433E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Interface

Erik:

Your clarification on the constraint sounds = reasonable to me and might well be what is in the draft. I don't recall = exactly how it is worded in the draft, so perhaps Ralph will want to = make sure we are clear on this.

- Bernie

-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.c= om]
Sent: Wednesday, September 19, 2001 5:50 AM
To: Bernie Volz (EUD)
Cc: 'Guja, ArturX'; dhcwg@ietf.org
Subject: RE: [dhcwg] Interface


> The client *MUST* send the messages through the = interface being configured.
> The client uses multicast messages and if = directly received by the server,
> that's the way it knows what link the client is = on. If a relay receives it
> and forwards it, that's how it can tag the = message having come from that
> link so that the server knows what link the = client is on. If the server
> doesn't know the correct link, it can't assign = the proper addresses.

Bernie,

I suspect that the real constraint is that the client = MUST send the
message on an interface attached to the same *LINK* = as the interface it
is trying to configure. When the client has multiple = interfaces attached to
the same link the server/relay can't tell which one = was used (short of
inspecting the source MAC address which may or may = not differ).

If the document will cover this distinction it would = make sense to
add a reference to = draft-ietf-ipngwg-scoping-arch-02.txt.

   Erik


------_=_NextPart_001_01C1411D.774433E0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 19 12:39:42 2001 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 MAA06000; Wed, 19 Sep 2001 12:39:42 -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 MAA12394; Wed, 19 Sep 2001 12:38:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12367 for ; Wed, 19 Sep 2001 12:38:42 -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 MAA05978 for ; Wed, 19 Sep 2001 12:38:39 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-230.ip.theriver.com [205.140.116.230]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f8JG9xv09676; Wed, 19 Sep 2001 09:09:59 -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 f8JGbIC00450; Wed, 19 Sep 2001 09:37:18 -0700 (MST) Message-Id: <200109191637.f8JGbIC00450@grosse.bisbee.fugue.com> To: Erik Nordmark cc: "Bernie Volz (EUD)" , "'Guja, ArturX'" , dhcwg@ietf.org Subject: Re: [dhcwg] Interface In-Reply-To: Message from Erik Nordmark of "Wed, 19 Sep 2001 11:50:02 +0200." Date: Wed, 19 Sep 2001 09:37:18 -0700 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > I suspect that the real constraint is that the client MUST send the > message on an interface attached to the same *LINK* as the interface it > is trying to configure. When the client has multiple interfaces attached to > the same link the server/relay can't tell which one was used (short of > inspecting the source MAC address which may or may not differ). How does the client know that two interfaces are attached to the same link? Better to leave well enough alone. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 19 13:17:43 2001 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 NAA06746; Wed, 19 Sep 2001 13:17:39 -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 NAA13108; Wed, 19 Sep 2001 13:09:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13082 for ; Wed, 19 Sep 2001 13:09:33 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06608 for ; Wed, 19 Sep 2001 13:09:27 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8JH7jp00994 for ; Wed, 19 Sep 2001 13:07:45 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 19 Sep 2001 13:07:48 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 13:07:51 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01A37200@zcard031.ca.nortel.com> From: "Yi Chen" To: dhcwg@ietf.org Date: Wed, 19 Sep 2001 13:07:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1412D.99715640" X-Orig: Subject: [dhcwg] (no subject) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1412D.99715640 Content-Type: text/plain; charset="iso-8859-1" Hi, Does any one know what kind of device uses a hardware type (htype) of "20"? I've looked at various "Assigned Number" RFC and found nothing. The longest list of valid htype is in RFC 1340 which goes from 1 to 16. TIA, Yi ------_=_NextPart_001_01C1412D.99715640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

Does any one know what kind of device = uses a hardware type (htype) of "20"? I've looked at various = "Assigned Number" RFC and found nothing. The longest list of = valid htype is in RFC 1340 which goes from 1 to 16.

TIA,

Yi

------_=_NextPart_001_01C1412D.99715640-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 19 13:37:58 2001 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 NAA07049; Wed, 19 Sep 2001 13:37:58 -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 NAA13844; Wed, 19 Sep 2001 13:34:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13819 for ; Wed, 19 Sep 2001 13:34:56 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07034 for ; Wed, 19 Sep 2001 13:34:49 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA06699; Wed, 19 Sep 2001 13:33:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20010919132854.041ea610@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Sep 2001 13:30:25 -0400 To: "Yi Chen" From: Ralph Droms Subject: Re: [dhcwg] (no subject) Cc: dhcwg@ietf.org In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01A37200@zcard031.ca.norte l.com> 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: X-BeenThere: dhcwg@ietf.org Check out http://www.iana.org/assignments/arp-parameters There's a table of hardware types: Number Hardware Type (hrd) References ------ ----------------------------------- ---------- 1 Ethernet (10Mb) [JBP] 2 Experimental Ethernet (3Mb) [JBP] 3 Amateur Radio AX.25 [PXK] ... 20 Serial Line [JBP] At 01:07 PM 9/19/2001 -0400, Yi Chen wrote: >Hi, > >Does any one know what kind of device uses a hardware type (htype) of >"20"? I've looked at various "Assigned Number" RFC and found nothing. The >longest list of valid htype is in RFC 1340 which goes from 1 to 16. > >TIA, > >Yi _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 19 14:19:21 2001 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 OAA07678; Wed, 19 Sep 2001 14:19:21 -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 OAA15170; Wed, 19 Sep 2001 14:18:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15142 for ; Wed, 19 Sep 2001 14:18:15 -0400 (EDT) Received: from 3miasto.net (root@3miasto.net [217.96.12.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07664 for ; Wed, 19 Sep 2001 14:18:13 -0400 (EDT) Received: from SCOPE (pc64.gdynia.sdi.tpnet.pl [213.77.131.64]) by 3miasto.net (8.11.6/8.11.0) with ESMTP id f8JIHVh03489 for ; Wed, 19 Sep 2001 20:17:34 +0200 Date: Wed, 19 Sep 2001 20:17:04 +0200 From: Artur Guja X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: Artur Guja X-Priority: 3 (Normal) Message-ID: <174593805.20010919201704@3miasto.net> To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Ports Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hello again, Question about ports: Let's assume that a client sends a message to the server from some port > 1024 (set manually or assigned by the system). Does the server respond to this port, or does it respond to port 546. In other words, is the port 546 for ALL messages from servers and relays to the client, or is it just for the Reconfig-Init and similar, i.e. exchanges INITIATED by the server. Artur G. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 19 17:29:49 2001 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 RAA11344; Wed, 19 Sep 2001 17:29:45 -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 RAA20599; Wed, 19 Sep 2001 17:24:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20568 for ; Wed, 19 Sep 2001 17:23:59 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11293 for ; Wed, 19 Sep 2001 17:23:54 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA09687 for ; Wed, 19 Sep 2001 17:22:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20010919171918.03b9b840@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Sep 2001 17:21:22 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Use of IPsec between relay agents and servers Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I'm about to add the text to specify the use of IPsec between relay agents and servers in DHCPv6. Any security experts out there want to volunteer to devise and write up a standard mechanism; or, shall I just specify the use of IPsec and reference RFC 2401? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 20 02:53:45 2001 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 CAA01642; Thu, 20 Sep 2001 02:53:45 -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 CAA11877; Thu, 20 Sep 2001 02:52:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11851 for ; Thu, 20 Sep 2001 02:52:42 -0400 (EDT) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01558 for ; Thu, 20 Sep 2001 02:52:39 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id GAA21449 for ; Thu, 20 Sep 2001 06:52:01 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001091923512900818 for ; Wed, 19 Sep 2001 23:51:29 -0700 Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id THAKCRQM; Wed, 19 Sep 2001 23:52:05 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 08:51:59 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A0247B425@alpha.igk.intel.com> From: "Guja, ArturX" To: "Dhcwg (E-mail)" Date: Thu, 20 Sep 2001 08:51:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" Subject: [dhcwg] Retransmission side Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Hello, > > I've looked hard into the recent discussion on retransmission. > I would like to get one thing straight, correct me if I'm wrong with this: > > If a message from the client to the server is "Lost In Transit", > the client retransmits. (OK so far :)) > > If a message from the server to the client is "LIT", the CLIENT > retransmits its message. The server notes the repeat and replies > with the same data as before. The server itself does not check, > whether the reply reached the client. > > (Except for Reconfig-Init, which is a server-initiated exchange, > so the server retransmits this message until it gets the REQUEST > from the client.) > > I hope I understood your intentions in this matter. > > Please, comment. > > Artur G. > (TUG student) _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 20 04:07:18 2001 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 EAA03447; Thu, 20 Sep 2001 04:07:14 -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 EAA14884; Thu, 20 Sep 2001 04:06:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14864 for ; Thu, 20 Sep 2001 04:06:16 -0400 (EDT) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03425 for ; Thu, 20 Sep 2001 04:06:12 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id IAA05290 for ; Thu, 20 Sep 2001 08:05:34 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001092001050229760 for ; Thu, 20 Sep 2001 01:05:02 -0700 Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T2TNQQFZ; Thu, 20 Sep 2001 01:05:38 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 10:05:32 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A0247B427@alpha.igk.intel.com> From: "Guja, ArturX" To: "Dhcwg (E-mail)" Date: Thu, 20 Sep 2001 10:05:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" Subject: [dhcwg] Client identification clarification Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Ok, here comes another one :))) Questions: How does the server identify the client? How does it choose what address to assign to the client? How I understood the answers: The clients sends a DUID option, that's clear (although the nature of the DUID is still unspecified, let's assume I've got random numbers or ethernet addresses as DUIDs). Fine. A client binding is a tuple. Fine. So does it suffice, if a server has an address range, eg: from 2000:: to 2000::ffff and assigns hose addresses to all clients requesting them. Or should there be some other distinction? What I'm looking here for is some way to let the administrator manage the addresses in a better way. One thing, though: The server does not know anything else about the client, apart from the DUID and IAID. Or does it??? Thank you all for your help here :))) Artur G. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 20 04:07:44 2001 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 EAA03486; Thu, 20 Sep 2001 04:07:44 -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 EAA14840; Thu, 20 Sep 2001 04:05:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14814 for ; Thu, 20 Sep 2001 04:05:42 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03419 for ; Thu, 20 Sep 2001 04:05:38 -0400 (EDT) From: Martin.Stiemerling@ccrle.nec.de Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f8K85rI44286; Thu, 20 Sep 2001 10:05:53 +0200 (CEST) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id 5BE70C112; Thu, 20 Sep 2001 10:04:40 +0200 (CEST) To: Artur Guja Subject: Re: [dhcwg] Ports Message-ID: <1000973080.3ba9a3183bc39@citadel.mobility.ccrle.nec.de> Date: Thu, 20 Sep 2001 10:04:40 +0200 (CEST) Cc: dhcwg@ietf.org References: <174593805.20010919201704@3miasto.net> In-Reply-To: <174593805.20010919201704@3miasto.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.83 Content-Transfer-Encoding: 8bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Hi, comment is below. Zitiere Artur Guja : > Hello again, > [...] > In other words, is the port 546 for ALL messages from servers and relays > to > the client, or is it just for the Reconfig-Init and similar, i.e. > exchanges > INITIATED by the server. It is only for messages which are initally from the server to client/relay or from relay to client. Used for the RECONIFG-INIT message. See draft 19, chapter 7.2. Martin ******************************************************** Martin Stiemerling NEC Europe Ltd. Network Laboratories Europe Adenauerplatz 6 69115 Heidelberg, Germany Fon: +49 6221 90511 13 Fax: +49 6221 90511 55 http://www.ccrle.nec.de/heidelberg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 20 04:20:49 2001 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 EAA03641; Thu, 20 Sep 2001 04:20:49 -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 EAA15193; Thu, 20 Sep 2001 04:17:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15168 for ; Thu, 20 Sep 2001 04:17:04 -0400 (EDT) Received: from mail.hycomat.co.uk (ns.hycomat.co.uk [194.153.168.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03600 for ; Thu, 20 Sep 2001 04:17:00 -0400 (EDT) Received: from rme by mail.hycomat.co.uk with local (Exim 3.15 #1) id 15jxoA-0008Nk-00 for dhcwg@ietf.org; Thu, 20 Sep 2001 06:59:38 +0000 Subject: Re: [dhcwg] Use of IPsec between relay agents and servers To: dhcwg@ietf.org Date: Thu, 20 Sep 2001 06:59:38 +0000 (UTC) In-Reply-To: <4.3.2.7.2.20010919171918.03b9b840@funnel.cisco.com> from "Ralph Droms" at Sep 19, 2001 05:21:22 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Ralph Meyer Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Why not removing relay agents at all, as proposed in "draft-prigent-dhcpv6-threats-00.txt(section 4)". With a site local prefix, that can only be used to reach the dhcp server. This prefix can predefinded or advertised over RAs. Ralpm M. > > I'm about to add the text to specify the use of IPsec between relay agents > and servers in DHCPv6. Any security experts out there want to volunteer to > devise and write up a standard mechanism; or, shall I just specify the use > of IPsec and reference RFC 2401? > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 20 04:25:00 2001 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 EAA03704; Thu, 20 Sep 2001 04:24:59 -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 EAA15411; Thu, 20 Sep 2001 04:23:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15380 for ; Thu, 20 Sep 2001 04:22:59 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03691 for ; Thu, 20 Sep 2001 04:22:55 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06215; Thu, 20 Sep 2001 02:22:06 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8K8MFg13464; Thu, 20 Sep 2001 10:22:15 +0200 (MET DST) Date: Thu, 20 Sep 2001 10:18:00 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] Interface To: Ted Lemon Cc: Erik Nordmark , "Bernie Volz (EUD)" , "'Guja, ArturX'" , dhcwg@ietf.org In-Reply-To: "Your message with ID" <200109191637.f8JGbIC00450@grosse.bisbee.fugue.com> Message-ID: 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: X-BeenThere: dhcwg@ietf.org > > > I suspect that the real constraint is that the client MUST send the > > message on an interface attached to the same *LINK* as the interface it > > is trying to configure. When the client has multiple interfaces attached to > > the same link the server/relay can't tell which one was used (short of > > inspecting the source MAC address which may or may not differ). > > How does the client know that two interfaces are attached to the same > link? Better to leave well enough alone. I suspect IEEE 802.3ad could tell the client such a fact. Of course one could view 802.3ad as providing a single interface to IP, but the scoped address architecture does include the ability of having IP "see" multiple interfaces to the same link. But that's beside the point - which is to not overconstrain the spec with MUSTs that aren't quite true. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 20 10:48:16 2001 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 KAA12212; Thu, 20 Sep 2001 10:48:16 -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 KAA28944; Thu, 20 Sep 2001 10:46:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28914 for ; Thu, 20 Sep 2001 10:46:23 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12168 for ; Thu, 20 Sep 2001 10:46:18 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA15961 for ; Thu, 20 Sep 2001 10:45:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20010920104148.03b61ef0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Sep 2001 10:43:26 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Error code option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org From the issues list generated at the WG meeting in London: * Add an "error code" option, to indicate errors not connected with a specific option WG consensus: yes; should allow inclusion of text message What error codes do we know of today that should be defined for this option? Please respond to me or to the mailing list... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 20 11:52:01 2001 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 LAA13934; Thu, 20 Sep 2001 11:52:01 -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 LAA00994; Thu, 20 Sep 2001 11:51:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00969 for ; Thu, 20 Sep 2001 11:51:06 -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 LAA13923 for ; Thu, 20 Sep 2001 11:51:02 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-229.ip.theriver.com [205.140.116.229]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f8KFMLv12165; Thu, 20 Sep 2001 08:22:21 -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 f8KFfcN02244; Thu, 20 Sep 2001 08:41:38 -0700 (MST) Message-Id: <200109201541.f8KFfcN02244@grosse.bisbee.fugue.com> To: Erik Nordmark cc: "Bernie Volz (EUD)" , "'Guja, ArturX'" , dhcwg@ietf.org Subject: Re: [dhcwg] Interface In-Reply-To: Message from Erik Nordmark of "Thu, 20 Sep 2001 10:18:00 +0200." Date: Thu, 20 Sep 2001 08:41:38 -0700 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > But that's beside the point - which is to not overconstrain the spec > with MUSTs that aren't quite true. The point is to come up with a working, implementable protocol definition, that does not only work if you happen to be running 802.3ad in a certain obscure implementation. Most implementors will not run into the corner case you've just described, but those same implementors have a pretty good chance of producing a non-interoperable client implementation if that MUST isn't there. In the corner case you've described, unless I am very much mistaken, the MUST will _not_ cause a problem. So the MUST should stay. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 20 13:03:30 2001 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 NAA15953; Thu, 20 Sep 2001 13:03:30 -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 NAA03487; Thu, 20 Sep 2001 13:02:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03462 for ; Thu, 20 Sep 2001 13:02:13 -0400 (EDT) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15911 for ; Thu, 20 Sep 2001 13:02:06 -0400 (EDT) Received: from 157.54.9.108 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Sep 2001 09:00:01 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Sep 2001 08:59:55 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Sep 2001 08:59:55 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Sep 2001 08:59:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [dhcwg] Error code option Date: Thu, 20 Sep 2001 08:59:48 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC162B760@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [dhcwg] Error code option thread-index: AcFB6y2+NPN78MvUQ+yWOWNowAD4gwAAMEaA From: "Thirumalesh Bhat" To: "Ralph Droms" , X-OriginalArrivalTime: 20 Sep 2001 15:59:48.0847 (UTC) FILETIME=[4678EFF0:01C141ED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA03463 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit The error code option can be defined as follows: +-----+-----+-----+-----+-----+-----+-----+-----+ ... | opt no | length | error | miscellaneous info such as err string +-----+-----+-----+-----+-----+-----+-----+-----+ ... We should define a basic set of error codes that can be extended by the implementation. Some of the error codes I can think of are: a) The server is out of addresses b) The server is not able to service the client request (Need for multiple error codes?) c) Invalid request for address d) Requested option not available e) The client could not be authenticated thx -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, September 20, 2001 7:43 AM To: dhcwg@ietf.org Subject: [dhcwg] Error code option From the issues list generated at the WG meeting in London: * Add an "error code" option, to indicate errors not connected with a specific option WG consensus: yes; should allow inclusion of text message What error codes do we know of today that should be defined for this option? Please respond to me or to the mailing list... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 20 13:25:11 2001 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 NAA16688; Thu, 20 Sep 2001 13:25:07 -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 NAA04007; Thu, 20 Sep 2001 13:16: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 NAA03984 for ; Thu, 20 Sep 2001 13:16:50 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16359 for ; Thu, 20 Sep 2001 13:16:47 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.179.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26335; Thu, 20 Sep 2001 10:16:02 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8KHFsg09599; Thu, 20 Sep 2001 19:15:55 +0200 (MET DST) Date: Thu, 20 Sep 2001 19:11:37 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] Interface To: Ted Lemon Cc: Erik Nordmark , "Bernie Volz (EUD)" , "'Guja, ArturX'" , dhcwg@ietf.org In-Reply-To: "Your message with ID" <200109201541.f8KFfcN02244@grosse.bisbee.fugue.com> Message-ID: 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: X-BeenThere: dhcwg@ietf.org > > > But that's beside the point - which is to not overconstrain the spec > > with MUSTs that aren't quite true. > > The point is to come up with a working, implementable protocol > definition, that does not only work if you happen to be running > 802.3ad in a certain obscure implementation. Ted, the tone of your statement reads like an attack on a particular unnamed implementation. I certainly did not describe an existing implementation - in fact I have no idea whether there exists an IEEE 802.3ad that does what I described. (And the whole mention about implementation was in response to a question whether there was an automatic way for hosts to determine that multiple interfaces are connected to the same link.) Sigh :-( What I did point out is that the IPv6 architecture allows multiple interfaces connected to the same link. That is the real issue. > Most implementors will not run into the corner case you've just > described, but those same implementors have a pretty good chance of > producing a non-interoperable client implementation if that MUST isn't > there. In the corner case you've described, unless I am very much > mistaken, the MUST will _not_ cause a problem. So the MUST should > stay. I don't think MUSTs are intended to prescribe rules for a subset of the implementations - their original use was to describe (often subtle) things that implementors had overlooked in the past that caused rather bad things to the network (such a broadcast storms). Today MUSTs are used to make firm statements for behavior that applies to all implementations. So you seem to be describing a case where a SHOULD applies. RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Alternatively text along the lines of this makes sense "... MUST (unless where the client has multiple interfaces connected to the same link [SCOPING-ARCH] in which case the ... MUST be for one of the interfaces connected to the same link) ..." Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 20 14:01:17 2001 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 OAA17800; Thu, 20 Sep 2001 14:01:13 -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 NAA05136; Thu, 20 Sep 2001 13:54:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05112 for ; Thu, 20 Sep 2001 13:54:08 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17539 for ; Thu, 20 Sep 2001 13:54:04 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f8KHrP712896 for ; Thu, 20 Sep 2001 12:53:25 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8KHrPR26472 for ; Thu, 20 Sep 2001 12:53:25 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Sep 20 12:53:24 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 12:53:24 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3638@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Erik Nordmark'" , Ted Lemon Cc: "'Guja, ArturX'" , dhcwg@ietf.org Subject: RE: [dhcwg] Interface Date: Thu, 20 Sep 2001 12:53:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C141FD.1FA06060" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C141FD.1FA06060 Content-Type: text/plain; charset="iso-8859-1" Perhaps I'm confused, but don't we have an issue that we should attempt to resolve when a client has multiple interfaces to the same link? A client may not know this. I believe IAs should be client specific, not interface specific. But, that still doesn't solve the problem because hows does the server know that there are two interfaces on that client? (Instead of treating all IAs to belong to the first interface.) This could lead to significant problems if we allow a server to tell a client all of the IAs for that client on that link (in an Advertise, for example). - Bernie -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] Sent: Thursday, September 20, 2001 1:12 PM To: Ted Lemon Cc: Erik Nordmark; Bernie Volz (EUD); 'Guja, ArturX'; dhcwg@ietf.org Subject: Re: [dhcwg] Interface > > > But that's beside the point - which is to not overconstrain the spec > > with MUSTs that aren't quite true. > > The point is to come up with a working, implementable protocol > definition, that does not only work if you happen to be running > 802.3ad in a certain obscure implementation. Ted, the tone of your statement reads like an attack on a particular unnamed implementation. I certainly did not describe an existing implementation - in fact I have no idea whether there exists an IEEE 802.3ad that does what I described. (And the whole mention about implementation was in response to a question whether there was an automatic way for hosts to determine that multiple interfaces are connected to the same link.) Sigh :-( What I did point out is that the IPv6 architecture allows multiple interfaces connected to the same link. That is the real issue. > Most implementors will not run into the corner case you've just > described, but those same implementors have a pretty good chance of > producing a non-interoperable client implementation if that MUST isn't > there. In the corner case you've described, unless I am very much > mistaken, the MUST will _not_ cause a problem. So the MUST should > stay. I don't think MUSTs are intended to prescribe rules for a subset of the implementations - their original use was to describe (often subtle) things that implementors had overlooked in the past that caused rather bad things to the network (such a broadcast storms). Today MUSTs are used to make firm statements for behavior that applies to all implementations. So you seem to be describing a case where a SHOULD applies. RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Alternatively text along the lines of this makes sense "... MUST (unless where the client has multiple interfaces connected to the same link [SCOPING-ARCH] in which case the ... MUST be for one of the interfaces connected to the same link) ..." Erik ------_=_NextPart_001_01C141FD.1FA06060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Interface

Perhaps I'm confused, but don't we have an issue that = we should attempt to resolve when a client has multiple interfaces to = the same link?

A client may not know this.

I believe IAs should be client specific, not = interface specific. But, that still doesn't solve the problem because = hows does the server know that there are two interfaces on that client? = (Instead of treating all IAs to belong to the first interface.) This = could lead to significant problems if we allow a server to tell a = client all of the IAs for that client on that link (in an Advertise, = for example).

- Bernie

-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.c= om]
Sent: Thursday, September 20, 2001 1:12 PM
To: Ted Lemon
Cc: Erik Nordmark; Bernie Volz (EUD); 'Guja, = ArturX'; dhcwg@ietf.org
Subject: Re: [dhcwg] Interface


>
> > But that's beside the point - which is to = not overconstrain the spec
> > with MUSTs that aren't quite true.
>
> The point is to come up with a working, = implementable protocol
> definition, that does not only work if you = happen to be running
> 802.3ad in a certain obscure = implementation.

Ted,

the tone of your statement reads like an attack on a = particular unnamed
implementation.  I certainly did not describe = an existing implementation -
in fact I have no idea whether there exists an IEEE = 802.3ad that does what
I described. (And the whole mention about = implementation was in response to
a question whether there was an automatic way for = hosts to determine that
multiple interfaces are connected to the same link.) = Sigh :-(

What I did point out is that the IPv6 architecture = allows multiple interfaces
connected to the same link. That is the real = issue.

> Most implementors will not run into the corner = case you've just
> described, but those same implementors have a = pretty good chance of
> producing a non-interoperable client = implementation if that MUST isn't
> there.  In the corner case you've = described, unless I am very much
> mistaken, the MUST will _not_ cause a = problem.  So the MUST should
> stay.

I don't think MUSTs are intended to prescribe rules = for a subset of
the implementations - their original use was to = describe (often subtle)
things that implementors had overlooked in the past = that caused rather bad
things to the network (such a broadcast = storms).
Today MUSTs are used to make firm statements for = behavior
that applies to all implementations.

So you seem to be describing a case where a SHOULD = applies. RFC 2119:
3. SHOULD   This word, or the adjective = "RECOMMENDED", mean that there
   may exist valid reasons in particular = circumstances to ignore a
   particular item, but the full = implications must be understood and
   carefully weighed before choosing a = different course.

Alternatively text along the lines of this makes = sense
        "... = MUST (unless where the client has multiple interfaces connected = to
        the same = link [SCOPING-ARCH] in which case the ... MUST be for one
        of the = interfaces connected to the same link) ..."

  Erik

------_=_NextPart_001_01C141FD.1FA06060-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 20 15:14:52 2001 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 PAA19420; Thu, 20 Sep 2001 15:14:52 -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 PAA07752; Thu, 20 Sep 2001 15:13:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07731 for ; Thu, 20 Sep 2001 15:13:07 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19383 for ; Thu, 20 Sep 2001 15:13:02 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f8KJBsQ24217 for ; Thu, 20 Sep 2001 14:11:54 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8KJBs304839 for ; Thu, 20 Sep 2001 14:11:54 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Sep 20 14:11:54 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 14:11:54 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B363D@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Thirumalesh Bhat'" , Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] Error code option Date: Thu, 20 Sep 2001 14:11:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14208.19E404F0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C14208.19E404F0 Content-Type: text/plain; charset="iso-8859-1" I think Ralph's previous drafts (-19) had a good set of error codes as a base. One other item ... I rather like the structure of error codes such as used by FTP and SMTP. By this I mean that having ranges of error code that indicate degrees of failure or status are nice. That way, if a new code is added, a client need not necessarily understand that explicit code to still behave properly. For my concepts of Confirm processing, there will need to be some type of response from a server that tells the client "the prefixes are OK but I can't confirm the individual addresses" - this really is more of a status. - Bernie -----Original Message----- From: Thirumalesh Bhat [mailto:thirub@windows.microsoft.com] Sent: Thursday, September 20, 2001 12:00 PM To: Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] Error code option The error code option can be defined as follows: +-----+-----+-----+-----+-----+-----+-----+-----+ ... | opt no | length | error | miscellaneous info such as err string +-----+-----+-----+-----+-----+-----+-----+-----+ ... We should define a basic set of error codes that can be extended by the implementation. Some of the error codes I can think of are: a) The server is out of addresses b) The server is not able to service the client request (Need for multiple error codes?) c) Invalid request for address d) Requested option not available e) The client could not be authenticated thx -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, September 20, 2001 7:43 AM To: dhcwg@ietf.org Subject: [dhcwg] Error code option From the issues list generated at the WG meeting in London: * Add an "error code" option, to indicate errors not connected with a specific option WG consensus: yes; should allow inclusion of text message What error codes do we know of today that should be defined for this option? Please respond to me or to the mailing list... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C14208.19E404F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Error code option

I think Ralph's previous drafts (-19) had a good set = of error codes as a base.

One other item ... I rather like the structure of = error codes such as used by FTP and SMTP. By this I mean that having = ranges of error code that indicate degrees of failure or status are = nice. That way, if a new code is added, a client need not necessarily = understand that explicit code to still behave properly.

For my concepts of Confirm processing, there will = need to be some type of response from a server that tells the client = "the prefixes are OK but I can't confirm the individual = addresses" - this really is more of a status.

- Bernie

-----Original Message-----
From: Thirumalesh Bhat [mailto:thirub@windows.micro= soft.com]
Sent: Thursday, September 20, 2001 12:00 PM
To: Ralph Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] Error code option


The error code option can be defined as = follows:

+-----+-----+-----+-----+-----+-----+-----+-----+ = ...
|    opt no |   = length  |   error   |  miscellaneous info = such as err
string
+-----+-----+-----+-----+-----+-----+-----+-----+ = ...

We should define a basic set of error codes that can = be extended by the
implementation.

Some of the error codes I can think of are:

a) The server is out of addresses
b) The server is not able to service the client = request (Need for
multiple error codes?)
c) Invalid request for address
d) Requested option not available
e) The client could not be authenticated

thx

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, September 20, 2001 7:43 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Error code option

 From the issues list generated at the WG = meeting in London:

    * Add an "error code" = option, to indicate errors
      not connected with a = specific option

      WG consensus: yes; = should allow inclusion of text message

What error codes do we know of today that should be = defined for
this option?  Please respond to me or to the = mailing list...

- Ralph


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

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

------_=_NextPart_001_01C14208.19E404F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 01:28:36 2001 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 BAA03103; Fri, 21 Sep 2001 01:28:35 -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 BAA02250; Fri, 21 Sep 2001 01:25:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02228 for ; Fri, 21 Sep 2001 01:25:54 -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 BAA02943 for ; Fri, 21 Sep 2001 01:25:52 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-229.ip.theriver.com [205.140.116.229]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f8L4vAv12987; Thu, 20 Sep 2001 21:57:10 -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 f8L5Ovt00458; Thu, 20 Sep 2001 22:24:57 -0700 (MST) Message-Id: <200109210524.f8L5Ovt00458@grosse.bisbee.fugue.com> To: Erik Nordmark cc: "Bernie Volz (EUD)" , "'Guja, ArturX'" , dhcwg@ietf.org Subject: Re: [dhcwg] Interface In-Reply-To: Message from Erik Nordmark of "Thu, 20 Sep 2001 19:11:37 +0200." Date: Thu, 20 Sep 2001 22:24:57 -0700 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I don't know what to say, Erik. It feels to me like you are trying to open the protocol to breakage in order to be pedantic. What matters to me is not the precise wording of RFC2119, but rather whether or not the protocol specification we arrive at will result in interoperable implementations. If we turn this particular MUST into a SHOULD, I promise you that there will be interoperability problems. I speak on the basis of a wealth of personal experience with DHCP client implementations. I argued with you about the particulars because you gave IEEE802.3ad as an example of why we need to change this MUST into a SHOULD, and it was not a valid example. So I would really appreciate it if we could keep this as a MUST. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 02:26:21 2001 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 CAA14133; Fri, 21 Sep 2001 02:26:21 -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 CAA03543; Fri, 21 Sep 2001 02:25:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03523 for ; Fri, 21 Sep 2001 02:25:28 -0400 (EDT) Received: from atlrel6.hp.com (atlrel6.hp.com [192.151.27.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14081 for ; Fri, 21 Sep 2001 02:25:25 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel6.hp.com (Postfix) with ESMTP id 91ED01F5DD for ; Fri, 21 Sep 2001 02:24:13 -0400 (EDT) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id LAA05608 for ; Fri, 21 Sep 2001 11:50:48 +0530 (IST) Reply-To: From: "Vijay Bhaskar A K" To: "Dhcwg (E-mail)" Date: Fri, 21 Sep 2001 11:54:09 +0530 Message-ID: <004401c14266$06810260$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Question on Relay address field Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit The latest draft on DHCPv6 says that, the client sends the request to All Agents multicast address. The Agents put its own address of the interface in which the client packet is recieved, in the Relay-forward packet. Assume the configuration one of the interface of the Agent is as follows. lan0 - A link local address lan0:1 - A site local address lan0:2 - A gloabal address Assume the packet is received from the client in the lan0 interface of the agent. Using our latest IPv6 APIs, we can identify this. But, we CANT identify at what alias interface ( lan0 or lan0:1 or lan0:2) in which the packet is received. Here the problem is, the relay cannot put its own link local address in the relay address field in the relay forward packet, since this info is useless. The question, SHOULD the relay put the address in lan0:1 (site local address) or lan0:2 (global address)in the relay address field? The DECISION of the relay is very important that depending up on the address it is sending the relay address field only, the server can allocate address to the client. Is there any solution to this problem? ~Vijay ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ _____Phone:_2051424______ ___Pager:_9624_371137____ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 03:34:44 2001 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 DAA17129; Fri, 21 Sep 2001 03:34:40 -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 DAA05565; Fri, 21 Sep 2001 03:33:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05540 for ; Fri, 21 Sep 2001 03:33:49 -0400 (EDT) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17124 for ; Fri, 21 Sep 2001 03:33:45 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id HAA15248 for ; Fri, 21 Sep 2001 07:33:07 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001092100323624073 for ; Fri, 21 Sep 2001 00:32:36 -0700 Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T2T6Y2WT; Fri, 21 Sep 2001 00:33:11 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 09:33:05 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A0247B42E@alpha.igk.intel.com> From: "Guja, ArturX" To: "Dhcwg (E-mail)" Date: Fri, 21 Sep 2001 09:32:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" Subject: [dhcwg] Overconstraining Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hello, One thing I noticed while implementing draft 19. It says, that after failing to get a REPLY to a REQUEST, the client MUST abort configuration attempt. Isn't it a bit harsh on the poor soul :))) After all, the server, whose ADVERTISE the client chose to answer, could have been shutdown or disconnected in the meantime. Shouldn't we allow the client to select another ADVERTISE and try again. I'd even risk allowing it to send a SOLICIT again, although I appreciate it could lead to perpetual flood of SOLICITS. But If a client got more than one ADVERTISE, it COULD select another one and try again, possibly with a different server. What do you think? Artur G. (TUG student) _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 04:03:03 2001 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 EAA17426; Fri, 21 Sep 2001 04:03: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 EAA06255; Fri, 21 Sep 2001 04:01:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06234 for ; Fri, 21 Sep 2001 04:01:42 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17420 for ; Fri, 21 Sep 2001 04:02:20 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.179.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA15355; Fri, 21 Sep 2001 01:01:37 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8L81ag24290; Fri, 21 Sep 2001 10:01:36 +0200 (MET DST) Date: Fri, 21 Sep 2001 09:57:18 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [dhcwg] Interface To: "Bernie Volz (EUD)" Cc: "'Erik Nordmark'" , Ted Lemon , "'Guja, ArturX'" , dhcwg@ietf.org In-Reply-To: "Your message with ID" <66F66129A77AD411B76200508B65AC697B3638@eambunt705.ena-east.ericsson.se> Message-ID: 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: X-BeenThere: dhcwg@ietf.org > Perhaps I'm confused, but don't we have an issue that we should attempt to > resolve when a client has multiple interfaces to the same link? > > A client may not know this. I think that the client either needs to know this or be very robust. For example, today a client might be confused to see the same subnet prefix appear on one interface. But that would be the norm when a client has multiple interfaces on the same link. > I believe IAs should be client specific, not interface specific. What problem are you trying to solve with this? When the client has multiple interfaces on different links I assume you want different IAs for those. Client that are aware that they have multiple interfaces on the same link might still want different IAs for those interfaces (so that they can get some inbound load spreading across the interfaces for instance). Erik > But, that > still doesn't solve the problem because hows does the server know that there > are two interfaces on that client? (Instead of treating all IAs to belong to > the first interface.) This could lead to significant problems if we allow a > server to tell a client all of the IAs for that client on that link (in an > Advertise, for example). > > - Bernie > > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Thursday, September 20, 2001 1:12 PM > To: Ted Lemon > Cc: Erik Nordmark; Bernie Volz (EUD); 'Guja, ArturX'; dhcwg@ietf.org > Subject: Re: [dhcwg] Interface > > > > > > > But that's beside the point - which is to not overconstrain the spec > > > with MUSTs that aren't quite true. > > > > The point is to come up with a working, implementable protocol > > definition, that does not only work if you happen to be running > > 802.3ad in a certain obscure implementation. > > Ted, > > the tone of your statement reads like an attack on a particular unnamed > implementation. I certainly did not describe an existing implementation - > in fact I have no idea whether there exists an IEEE 802.3ad that does what > I described. (And the whole mention about implementation was in response to > a question whether there was an automatic way for hosts to determine that > multiple interfaces are connected to the same link.) Sigh :-( > > What I did point out is that the IPv6 architecture allows multiple interfaces > connected to the same link. That is the real issue. > > > Most implementors will not run into the corner case you've just > > described, but those same implementors have a pretty good chance of > > producing a non-interoperable client implementation if that MUST isn't > > there. In the corner case you've described, unless I am very much > > mistaken, the MUST will _not_ cause a problem. So the MUST should > > stay. > > I don't think MUSTs are intended to prescribe rules for a subset of > the implementations - their original use was to describe (often subtle) > things that implementors had overlooked in the past that caused rather bad > things to the network (such a broadcast storms). > Today MUSTs are used to make firm statements for behavior > that applies to all implementations. > > So you seem to be describing a case where a SHOULD applies. RFC 2119: > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > Alternatively text along the lines of this makes sense > "... MUST (unless where the client has multiple interfaces connected to > the same link [SCOPING-ARCH] in which case the ... MUST be for one > of the interfaces connected to the same link) ..." > > Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 04:33:25 2001 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 EAA17630; Fri, 21 Sep 2001 04:33:25 -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 EAA07069; Fri, 21 Sep 2001 04:31:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07000 for ; Fri, 21 Sep 2001 04:31:18 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17624 for ; Fri, 21 Sep 2001 04:31:56 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.179.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA24459; Fri, 21 Sep 2001 01:31:16 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8L8VEg28095; Fri, 21 Sep 2001 10:31:14 +0200 (MET DST) Date: Fri, 21 Sep 2001 10:26:56 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] Interface To: Ted Lemon Cc: Erik Nordmark , "Bernie Volz (EUD)" , "'Guja, ArturX'" , dhcwg@ietf.org In-Reply-To: "Your message with ID" <200109210524.f8L5Ovt00458@grosse.bisbee.fugue.com> Message-ID: 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: X-BeenThere: dhcwg@ietf.org > > I don't know what to say, Erik. It feels to me like you are trying > to open the protocol to breakage in order to be pedantic. What > matters to me is not the precise wording of RFC2119, but rather > whether or not the protocol specification we arrive at will result in > interoperable implementations. > > If we turn this particular MUST into a SHOULD, I promise you that > there will be interoperability problems. I speak on the basis of a > wealth of personal experience with DHCP client implementations. OK - I sense the equivalent of grade inflation here caused by presumed clueless implementors. Need to update RFC 2119 with the "REALLY MUST" and "REALLY MUST NOT" to deal with this :-) :-) > I argued with you about the particulars because you gave IEEE802.3ad > as an example of why we need to change this MUST into a SHOULD, and it > was not a valid example. So I would really appreciate it if we could > keep this as a MUST. No, I did NOT! Please re-read the email thread. The reason for changing it (or clarifying the constraint) was draft-ietf-ipngwg-scoping-arch-02.txt. But I haven't read what the actual text says so this might all be a red herring. I responded to an email which had an explanation which essentially said (with significant ad-libbing) MUST send on that interface since otherwise the agent will be confused. This statement is incorrect. But if the statement is instead MUST send on that interface to ensure that the packet is guaranteed to appear on the correct link (*). If the message appears on the wrong link the agent will be confused. *) This ensures that the packet arrives on the correct link even in the case when a node has multiple interfaces on the same link but has incorrect information about which interfaces connect to which links. I think the footnote can be omitted - but it might help future readers to understand the background. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 05:40:00 2001 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 FAA18021; Fri, 21 Sep 2001 05:40:00 -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 FAA08587; Fri, 21 Sep 2001 05:38:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08562 for ; Fri, 21 Sep 2001 05:38:26 -0400 (EDT) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18015 for ; Fri, 21 Sep 2001 05:39:03 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id JAA17436 for ; Fri, 21 Sep 2001 09:38:26 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001092102373231285 for ; Fri, 21 Sep 2001 02:37:32 -0700 Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T2T6YKF9; Fri, 21 Sep 2001 02:38:07 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 11:38:01 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A0247B430@alpha.igk.intel.com> From: "Guja, ArturX" To: "Dhcwg (E-mail)" Date: Fri, 21 Sep 2001 11:37:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" Subject: [dhcwg] Address status Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hello, In the address part of IO option, there is a field called "address status". What is the meaning of this field, or more specifically, what values can it take? I assume that it is different from the IA status, or isn't it? If it is, what is the meaning of IA status? Please, clarify. Artur _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 06:14:57 2001 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 GAA18370; Fri, 21 Sep 2001 06:14:56 -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 GAA09349; Fri, 21 Sep 2001 06:13:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09322 for ; Fri, 21 Sep 2001 06:13:37 -0400 (EDT) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18365 for ; Fri, 21 Sep 2001 06:14:14 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id KAA25493 for ; Fri, 21 Sep 2001 10:13:36 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001092103124308342 for ; Fri, 21 Sep 2001 03:12:43 -0700 Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T2T6YKT5; Fri, 21 Sep 2001 03:13:17 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 12:13:12 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A0247B431@alpha.igk.intel.com> From: "Guja, ArturX" To: "Dhcwg (E-mail)" Date: Fri, 21 Sep 2001 12:13:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" Subject: [dhcwg] Implementation problem Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Can a client get ANY address from the available pools, or does it only get a prefix to be filled with its interface identifier? Or, is it the server's duty to make sure, that the addresses passed to the client are of the form: prefix + interface ID If so, the server could take the interface ID of the client from the client's link local address (if it still gets it, I'm not sure after all the changes here). Does the client check the addresses' structure, or does it assign those addresses to its interfaces on an "AS IS" principle? Artur G. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 09:59:28 2001 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 JAA25574; Fri, 21 Sep 2001 09:59:28 -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 JAA14058; Fri, 21 Sep 2001 09:57:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14037 for ; Fri, 21 Sep 2001 09:57:56 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25498 for ; Fri, 21 Sep 2001 09:58:33 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-55.cisco.com [10.82.224.55]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA14402 for ; Fri, 21 Sep 2001 09:57:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20010921080145.03ca5ec0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Sep 2001 09:56:19 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Clarification on issue from London Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org One of the issues we came to consensus on in London affects server response to Advertise requests: * Server does not respond to Solicit when client wants addresses and server has no addresses WG consensus: Server should be allowed to respond Unless someone comes up with a different scenario, I'm going to add text allowing a server to respond with an Advertise that includes a error code option (new option, defined in -20 draft) with error code Unavail (see 7.4.1 in -19 draft). The client may choose to display the error message in the error code option as additional information for the user. Otherwise, the client ignores Advertise messages that include an error code option. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 10:05:03 2001 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 KAA25879; Fri, 21 Sep 2001 10:04:59 -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 KAA14512; Fri, 21 Sep 2001 10:03:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14487 for ; Fri, 21 Sep 2001 10:03:36 -0400 (EDT) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25846 for ; Fri, 21 Sep 2001 10:04:13 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id OAA24185 for ; Fri, 21 Sep 2001 14:03:35 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001092107030409746 for ; Fri, 21 Sep 2001 07:03:04 -0700 Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T2T6YNRF; Fri, 21 Sep 2001 07:03:38 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 16:03:30 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A0247B438@alpha.igk.intel.com> From: "Guja, ArturX" To: "Dhcwg (E-mail)" Date: Fri, 21 Sep 2001 16:03:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" Subject: [dhcwg] Rebind failure behavior Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hello, I have encountered one totally counter-intuitive thing in the draft 19. The text reads as follows: " The server will respond to the Rebind message with a Reply message. If no Reply message is received within REP_MSG_TIMEOUT milliseconds, the client retransmits the Rebind with the same transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits again. The client continues this process until a Reply is received " So, basically, if the first server is down, and no other server is willing to respond to a REBIND (they don't have to, if they do not "feel" authoritative about this particular client's leases) the client goes HANG and stays there. I believe this will have to be changed to some timeout or something. Artur Guja _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 12:12:05 2001 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 MAA29714; Fri, 21 Sep 2001 12:12:01 -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 MAA18101; Fri, 21 Sep 2001 12:10:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18073 for ; Fri, 21 Sep 2001 12:10:18 -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 MAA29663 for ; Fri, 21 Sep 2001 12:10:55 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-229.ip.theriver.com [205.140.116.229]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f8LFgEv14271; Fri, 21 Sep 2001 08:42:14 -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 f8LGA9t01896; Fri, 21 Sep 2001 09:10:09 -0700 (MST) Message-Id: <200109211610.f8LGA9t01896@grosse.bisbee.fugue.com> To: Erik Nordmark cc: "Bernie Volz (EUD)" , "'Guja, ArturX'" , dhcwg@ietf.org Subject: Re: [dhcwg] Interface In-Reply-To: Message from Erik Nordmark of "Fri, 21 Sep 2001 10:26:56 +0200." Date: Fri, 21 Sep 2001 09:10:09 -0700 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > OK - I sense the equivalent of grade inflation here caused by > presumed clueless implementors. Need to update RFC 2119 with the > "REALLY MUST" and "REALLY MUST NOT" to deal with this :-) :-) *grin* I think there's some truth to it, but you're making it out to be worse than it is. > No, I did NOT! Please re-read the email thread. Oops, sorry. > MUST send on that interface since otherwise the agent will be > confused. > This statement is incorrect. Okay, I'll buy that. > But if the statement is instead > MUST send on that interface to ensure that the packet is guaranteed > to appear on the correct link (*). If the message appears on the wrong > link the agent will be confused. > *) This ensures that the packet arrives on the correct link even > in the case when a node has multiple interfaces on the same link > but has incorrect information about which interfaces connect to > which links. > I think the footnote can be omitted - but it might help future readers to > understand the background. This wording works for me (I'll let Ralph decide about the footnote). Thanks for continuing to beat me up about this! :'} _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 23:54:44 2001 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 XAA12853; Fri, 21 Sep 2001 23:54:43 -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 XAA02905; Fri, 21 Sep 2001 23:52:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02878 for ; Fri, 21 Sep 2001 23:52:41 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12843 for ; Fri, 21 Sep 2001 23:53:18 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA31537; Fri, 21 Sep 2001 23:51:10 -0400 Date: Fri, 21 Sep 2001 23:51:09 -0400 (EDT) From: Jim Bound To: Vijay Bhaskar A K Cc: "Dhcwg (E-mail)" Subject: Re: [dhcwg] Question on Relay address field In-Reply-To: <004401c14266$06810260$2f290a0f@india.hp.com> Message-Id: 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: X-BeenThere: dhcwg@ietf.org Vijay, I am not clear why you can't tell the alias. This will be a function of the scoping code for IPv6 as the interface in your example is using scoping (your aliases) and that is code that would have to be part of the base IPv6 stack to return from the API index routines? I am not clear this is a dhcp problem but an IPv6 implementation problem in general we all are working on now? Maybe I am missing your issue though? thanks /jim On Fri, 21 Sep 2001, Vijay Bhaskar A K wrote: > The latest draft on DHCPv6 says that, the client sends the > request to All Agents multicast address. The Agents put its > own address of the interface in which the client packet is > recieved, in the Relay-forward packet. > > Assume the configuration one of the interface of the Agent is as follows. > > lan0 - A link local address > lan0:1 - A site local address > lan0:2 - A gloabal address > > Assume the packet is received from the client in the lan0 interface of the > agent. > Using our latest IPv6 APIs, we can identify this. > But, we CANT identify at what alias interface ( lan0 or lan0:1 or lan0:2) > in which the packet is received. > > Here the problem is, the relay cannot put its own link local address > in the relay address field in the relay forward packet, since this > info is useless. > > The question, SHOULD the relay put the address in lan0:1 (site local > address) or lan0:2 (global address)in the relay address field? > The DECISION of the relay is very important that depending up on the > address it is sending the relay address field only, the server can > allocate address to the client. Is there any solution to this > problem? > ~Vijay > > > > ____Vijay_Bhaskar_A_K____ > ______Inet_Services______ > ________HP_ISO___________ > _____Phone:_2051424______ > ___Pager:_9624_371137____ > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 23:55:13 2001 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 XAA12883; Fri, 21 Sep 2001 23:55:13 -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 XAA02948; Fri, 21 Sep 2001 23:53:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02923 for ; Fri, 21 Sep 2001 23:53:15 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12848 for ; Fri, 21 Sep 2001 23:53:53 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA08945; Fri, 21 Sep 2001 23:53:13 -0400 Date: Fri, 21 Sep 2001 23:53:13 -0400 (EDT) From: Jim Bound To: "Guja, ArturX" Cc: "Dhcwg (E-mail)" Subject: Re: [dhcwg] Address status In-Reply-To: <413FBB0BA5AED1119122000083234B1A0247B430@alpha.igk.intel.com> Message-Id: 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: X-BeenThere: dhcwg@ietf.org Yes we should clarify this for where we want to use it and leave anything else reserved. /jim On Fri, 21 Sep 2001, Guja, ArturX wrote: > Hello, > > In the address part of IO option, there is a field > called "address status". > > What is the meaning of this field, or more specifically, > what values can it take? > I assume that it is different from the IA status, or isn't it? > If it is, what is the meaning of IA status? > > Please, clarify. > > Artur > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 23:55:26 2001 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 XAA12911; Fri, 21 Sep 2001 23:55:26 -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 XAA02869; Fri, 21 Sep 2001 23:52:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02839 for ; Fri, 21 Sep 2001 23:52:20 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12839 for ; Fri, 21 Sep 2001 23:52:58 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA02064; Fri, 21 Sep 2001 23:52:19 -0400 Date: Fri, 21 Sep 2001 23:52:19 -0400 (EDT) From: Jim Bound To: "Guja, ArturX" Cc: "Dhcwg (E-mail)" Subject: Re: [dhcwg] Overconstraining In-Reply-To: <413FBB0BA5AED1119122000083234B1A0247B42E@alpha.igk.intel.com> Message-Id: 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: X-BeenThere: dhcwg@ietf.org If it was a SHOULD would that be fine? I don't think going back to solicit in the spec is prudent though? /jim On Fri, 21 Sep 2001, Guja, ArturX wrote: > Hello, > > One thing I noticed while implementing draft 19. > It says, that after failing to get a REPLY to a REQUEST, > the client MUST abort configuration attempt. Isn't it a bit harsh > on the poor soul :))) > > After all, the server, whose ADVERTISE the client chose to answer, > could have been shutdown or disconnected in the meantime. > Shouldn't we allow the client to select another ADVERTISE and try again. > I'd even risk allowing it to send a SOLICIT again, although I appreciate it > could > lead to perpetual flood of SOLICITS. > > But If a client got more than one ADVERTISE, it COULD select another one > and try again, possibly with a different server. > > What do you think? > > Artur G. > (TUG student) > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 23:56:46 2001 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 XAA12944; Fri, 21 Sep 2001 23:56:45 -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 XAA03023; Fri, 21 Sep 2001 23:55:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02992 for ; Fri, 21 Sep 2001 23:55:09 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12939 for ; Fri, 21 Sep 2001 23:55:47 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA18874; Fri, 21 Sep 2001 23:55:09 -0400 Date: Fri, 21 Sep 2001 23:55:09 -0400 (EDT) From: Jim Bound To: "Guja, ArturX" Cc: "Dhcwg (E-mail)" Subject: Re: [dhcwg] Implementation problem In-Reply-To: <413FBB0BA5AED1119122000083234B1A0247B431@alpha.igk.intel.com> Message-Id: 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: X-BeenThere: dhcwg@ietf.org We have gone back and forth on this. I am assuming we are now at the state where you use it as-is? I believe that was consensus of last round? If we don't do this it gets too complicated to finish this spec for last call. In the future we can extend address types and scenarios. /jim On Fri, 21 Sep 2001, Guja, ArturX wrote: > Can a client get ANY address from the available pools, > or does it only get a prefix to be filled with its interface identifier? > > Or, is it the server's duty to make sure, that the addresses passed > to the client are of the form: > prefix + interface ID > If so, the server could take the interface ID of the client from the > client's > link local address (if it still gets it, I'm not sure after all the changes > here). > > Does the client check the addresses' structure, or does it assign those > addresses to its interfaces on an "AS IS" principle? > > Artur G. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 21 23:58:50 2001 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 XAA12979; Fri, 21 Sep 2001 23:58:50 -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 XAA03064; Fri, 21 Sep 2001 23:56:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA03040 for ; Fri, 21 Sep 2001 23:56:50 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12973 for ; Fri, 21 Sep 2001 23:57:26 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA31364; Fri, 21 Sep 2001 23:56:48 -0400 Date: Fri, 21 Sep 2001 23:56:48 -0400 (EDT) From: Jim Bound To: "Guja, ArturX" Cc: "Dhcwg (E-mail)" Subject: Re: [dhcwg] Rebind failure behavior In-Reply-To: <413FBB0BA5AED1119122000083234B1A0247B438@alpha.igk.intel.com> Message-Id: 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: X-BeenThere: dhcwg@ietf.org this is a bug...thanks /jim On Fri, 21 Sep 2001, Guja, ArturX wrote: > Hello, > > I have encountered one totally counter-intuitive thing in the > draft 19. > > The text reads as follows: > " The server will respond to the Rebind message with a Reply message. > If no Reply message is received within REP_MSG_TIMEOUT milliseconds, > the client retransmits the Rebind with the same transaction-ID, and > doubles the REP_MSG_TIMEOUT value, and waits again. The client > continues this process until a Reply is received " > > So, basically, if the first server is down, and no other server > is willing to respond to a REBIND (they don't have to, if they do > not "feel" authoritative about this particular client's leases) > the client goes HANG and stays there. > > I believe this will have to be changed to some timeout or > something. > > Artur Guja > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 22 07:02:09 2001 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 HAA29479; Sat, 22 Sep 2001 07:02:09 -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 GAA17155; Sat, 22 Sep 2001 06:59:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17137 for ; Sat, 22 Sep 2001 06:59:51 -0400 (EDT) Received: from 3miasto.net (root@3miasto.net [217.96.12.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29454 for ; Sat, 22 Sep 2001 06:59:46 -0400 (EDT) Received: from 192.168.254.42 (pc64.gdynia.sdi.tpnet.pl [213.77.131.64]) by 3miasto.net (8.11.6/8.11.0) with ESMTP id f8MAxah22732; Sat, 22 Sep 2001 12:59:37 +0200 Date: Sat, 22 Sep 2001 12:59:01 +0200 From: Artur Guja X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: Artur Guja X-Priority: 3 (Normal) Message-ID: <1141412763.20010922125901@3miasto.net> To: Jim Bound CC: "Dhcwg (E-mail)" Subject: Re[2]: [dhcwg] Overconstraining In-reply-To: References: 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: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit JB> If it was a SHOULD would that be fine? I don't think going back to JB> solicit in the spec is prudent though? Of course, going back to SOLICIT is a bit wierd. But if the client got more than one advertise, it chooses the best one. If this one fails, it could settle on a less preferable one. Of course, it there was only one ADVERTISE, or the rest of them were unacceptable, the client MUST abort (in my opinion), or else we could get an infinite loop of SOLICITs. Artur _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 22 09:00:35 2001 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 JAA00470; Sat, 22 Sep 2001 09:00:34 -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 IAA19278; Sat, 22 Sep 2001 08:58:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19253 for ; Sat, 22 Sep 2001 08:58:41 -0400 (EDT) Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00433 for ; Sat, 22 Sep 2001 08:58:38 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel2.hp.com (Postfix) with ESMTP id 7E27AAB9; Sat, 22 Sep 2001 05:58:39 -0700 (PDT) Received: from india.hp.com (sakreddy@deer.india.hp.com [15.10.44.44]) by hpuxsrv.india.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id SAA06847; Sat, 22 Sep 2001 18:25:14 +0530 (IST) Message-ID: <3BAC8C32.90F8178A@india.hp.com> Date: Sat, 22 Sep 2001 18:33:46 +0530 From: "Anil Kumar Reddy. S" Reply-To: sakreddy@india.hp.com Organization: Hewlett-Packard X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: Jim Bound Cc: "Dhcwg (E-mail)" Subject: Re: [dhcwg] Question on Relay address field References: Content-Type: multipart/alternative; boundary="------------901BF8E612B7BA5985A533B3" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --------------901BF8E612B7BA5985A533B3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jim, As per IPv6 rfc2292bis (draft), through the socket option IPV6_RECVPKTINFO we can get the index of the interface through which the client packet is received. But the index will be same for all aliases and the primary address of the interface. So, if we get the interface index and try to get the address of that, then we get the link local address only because the primary address of an interface is always link local. ( Hope, I am clear in explaining ;-)) ) In this case, how the relay is expected to work, when an interface is configured with the addresses given by Vijay ?? Which address it has to consider ?? - Anil Jim Bound wrote: > Vijay, > > I am not clear why you can't tell the alias. This will be a function of > the scoping code for IPv6 as the interface in your example is using > scoping (your aliases) and that is code that would have to be part of the > base IPv6 stack to return from the API index routines? > > I am not clear this is a dhcp problem but an IPv6 implementation problem > in general we all are working on now? > > Maybe I am missing your issue though? > > thanks > > /jim > > On Fri, 21 Sep 2001, Vijay Bhaskar A K wrote: > > > The latest draft on DHCPv6 says that, the client sends the > > request to All Agents multicast address. The Agents put its > > own address of the interface in which the client packet is > > recieved, in the Relay-forward packet. > > > > Assume the configuration one of the interface of the Agent is as follows. > > > > lan0 - A link local address > > lan0:1 - A site local address > > lan0:2 - A gloabal address > > > > Assume the packet is received from the client in the lan0 interface of the > > agent. > > Using our latest IPv6 APIs, we can identify this. > > But, we CANT identify at what alias interface ( lan0 or lan0:1 or lan0:2) > > in which the packet is received. > > > > Here the problem is, the relay cannot put its own link local address > > in the relay address field in the relay forward packet, since this > > info is useless. > > > > The question, SHOULD the relay put the address in lan0:1 (site local > > address) or lan0:2 (global address)in the relay address field? > > The DECISION of the relay is very important that depending up on the > > address it is sending the relay address field only, the server can > > allocate address to the client. Is there any solution to this > > problem? > > ~Vijay > > > > > > > > ____Vijay_Bhaskar_A_K____ > > ______Inet_Services______ > > ________HP_ISO___________ > > _____Phone:_2051424______ > > ___Pager:_9624_371137____ > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > http://www1.ietf.org/mailman/listinfo/dhcwg > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Anil Kumar Reddy .S | Senior Software Engineer, | Hewlett-Packard, | Bangalore, INDIA. | | Telnet # 847-1426 | Ph. 2251554 Ext: 1426 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= --------------901BF8E612B7BA5985A533B3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jim,

    As per IPv6 rfc2292bis (draft), through the socket option IPV6_RECVPKTINFO
    we can get the index of the interface through which the client packet is
    received. But the index will be same for all aliases and the
    primary address of the interface. So, if we get the interface index
    and try to get the address of that, then we get the link local address only
    because the primary address of an interface is always link local.
    (  Hope, I am clear in explaining   ;-))  )

    In this case, how the relay is expected to work, when an interface
    is configured with the addresses given by Vijay ?? Which address it has
    to consider ??

- Anil

Jim Bound wrote:

Vijay,

I am not clear why you can't tell the alias.  This will be a function of
the scoping code for IPv6 as the interface in your example is using
scoping (your aliases) and that is code that would have to be part of the
base IPv6 stack to return from the API index routines?

I am not clear this is a dhcp problem but an IPv6 implementation problem
in general we all are working on now?

Maybe I am missing your issue though?

thanks

/jim

On Fri, 21 Sep 2001, Vijay Bhaskar A K wrote:

> The latest draft on DHCPv6 says that, the client sends the
> request to All Agents multicast address. The Agents put its
> own address of the interface in which the client packet is
> recieved, in the Relay-forward packet.
>
> Assume the configuration one of the interface of the Agent is as follows.
>
> lan0   -  A link local address
> lan0:1 -  A site local address
> lan0:2 -  A gloabal address
>
> Assume the packet is received from the client in the lan0 interface of the
> agent.
> Using our latest IPv6 APIs, we can identify this.
> But, we CANT identify at what alias interface ( lan0 or lan0:1 or lan0:2)
> in which the packet is received.
>
> Here the problem is, the relay cannot put its own link local address
> in the relay address field in the relay forward packet, since this
> info is useless.
>
> The question, SHOULD the relay put the address in lan0:1 (site local
> address) or lan0:2 (global address)in the relay address field?
> The DECISION of the relay is very important that depending up on the
> address it is sending the relay address field only, the server can
> allocate address to the client. Is there any solution to this
> problem?
> ~Vijay
>
>
>
> ____Vijay_Bhaskar_A_K____
> ______Inet_Services______
> ________HP_ISO___________
> _____Phone:_2051424______
> ___Pager:_9624_371137____
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> http://www1.ietf.org/mailman/listinfo/dhcwg
>

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

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|  Anil Kumar Reddy .S
|  Senior Software Engineer,
|  Hewlett-Packard,
|  Bangalore, INDIA.
|  
|  Telnet # 847-1426
|  Ph. 2251554 Ext: 1426
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  --------------901BF8E612B7BA5985A533B3-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 22 12:26:14 2001 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 MAA02109; Sat, 22 Sep 2001 12:26:14 -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 MAA23336; Sat, 22 Sep 2001 12:24:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23311 for ; Sat, 22 Sep 2001 12:24:07 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02102 for ; Sat, 22 Sep 2001 12:24:04 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA12397; Sat, 22 Sep 2001 12:23:55 -0400 Date: Sat, 22 Sep 2001 12:23:55 -0400 (EDT) From: Jim Bound To: Artur Guja Cc: "Dhcwg (E-mail)" Subject: Re: Re[2]: [dhcwg] Overconstraining In-Reply-To: <1141412763.20010922125901@3miasto.net> Message-Id: 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: X-BeenThere: dhcwg@ietf.org ralph and I got input and it will be clear in the next rev that the client can go use less preferred advertise if it chooses. making it a SHOULD would permit implementors to do this. SHOULD means do this unless you have a really good reason to not do this. /jim On Sat, 22 Sep 2001, Artur Guja wrote: > > JB> If it was a SHOULD would that be fine? I don't think going back to > JB> solicit in the spec is prudent though? > > Of course, going back to SOLICIT is a bit wierd. > > But if the client got more than one advertise, > it chooses the best one. If this one fails, > it could settle on a less preferable one. > Of course, it there was only one ADVERTISE, > or the rest of them were unacceptable, the client > MUST abort (in my opinion), or else we could get an > infinite loop of SOLICITs. > > Artur > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 22 12:55:45 2001 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 MAA02309; Sat, 22 Sep 2001 12:55:45 -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 MAA23848; Sat, 22 Sep 2001 12:54:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23824 for ; Sat, 22 Sep 2001 12:54:22 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02302 for ; Sat, 22 Sep 2001 12:54:21 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06036; Sat, 22 Sep 2001 12:52:53 -0400 Date: Sat, 22 Sep 2001 12:52:53 -0400 (EDT) From: Jim Bound To: "Anil Kumar Reddy. S" Cc: "Dhcwg (E-mail)" Subject: Re: [dhcwg] Question on Relay address field In-Reply-To: <3BAC8C32.90F8178A@india.hp.com> Message-Id: 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: X-BeenThere: dhcwg@ietf.org Anil, OK I get it. Multiple issues here and they are not dhcp issues though. We in dhcp must assume you can get the interface address it came in on within an IPv6 implementation and thats not our job here to work that. But let me try to suggest how I would do it. First assume you can get the interface index from 2292-bis or you do it on your implementation via some other means (sysctl/ioctl). You then do an if_nameindex() call to get all interface names from the base api not the advanced api. 4.3 Return All Interface Names and Indexes The if_nameindex structure holds the information about a single interface and is defined as a result of including the header. struct if_nameindex { unsigned int if_index; /* 1, 2, ... */ char *if_name; /* null terminated name: "le0", ... */ }; The final function returns an array of if_nameindex structures, one structure per interface. struct if_nameindex *if_nameindex(void); Then we would need to call our implementation defined functions to return each address for each interface name. At this point the relay needs to use the proper scoping to get to the server. Because we are embedding the address in the relay-forward option we must do what IPv6 will do with source address selection for sending IP packets in general which is select the proper scope for the relay-address. I would argue until IPv6 scoping is more widely implemented and its not even been tested at our bake-offs for interoperability just yet the relay needs to configure a table for each interface at its node and depending on the scope of the server IP dst address select the best relay-address for that interface. The default should be a global address for each address interface at the relay. The other thing we can do is add to 2292-bis or build draft in ipng for extensiion to the base api to return all addresses to if_nameindex(). The base API is frozen and in the IEEE becoming standard now. So we cannot change that now or break existing production implementations. But I do not think this systems programming implementation issue should affect the dhcp ipv6 standard at all and we should move forward. This is an API issue again not dhcpv6 protocol issue. And we can all make this work. My input to you. /jim On Sat, 22 Sep 2001, Anil Kumar Reddy. S wrote: > Hi Jim, > > As per IPv6 rfc2292bis (draft), through the socket option IPV6_RECVPKTINFO > we can get the index of the interface through which the client packet is > received. But the index will be same for all aliases and the > primary address of the interface. So, if we get the interface index > and try to get the address of that, then we get the link local address only > > because the primary address of an interface is always link local. > ( Hope, I am clear in explaining ;-)) ) > > In this case, how the relay is expected to work, when an interface > is configured with the addresses given by Vijay ?? Which address it has > to consider ?? > > - Anil > > Jim Bound wrote: > > > Vijay, > > > > I am not clear why you can't tell the alias. This will be a function of > > the scoping code for IPv6 as the interface in your example is using > > scoping (your aliases) and that is code that would have to be part of the > > base IPv6 stack to return from the API index routines? > > > > I am not clear this is a dhcp problem but an IPv6 implementation problem > > in general we all are working on now? > > > > Maybe I am missing your issue though? > > > > thanks > > > > /jim > > > > On Fri, 21 Sep 2001, Vijay Bhaskar A K wrote: > > > > > The latest draft on DHCPv6 says that, the client sends the > > > request to All Agents multicast address. The Agents put its > > > own address of the interface in which the client packet is > > > recieved, in the Relay-forward packet. > > > > > > Assume the configuration one of the interface of the Agent is as follows. > > > > > > lan0 - A link local address > > > lan0:1 - A site local address > > > lan0:2 - A gloabal address > > > > > > Assume the packet is received from the client in the lan0 interface of the > > > agent. > > > Using our latest IPv6 APIs, we can identify this. > > > But, we CANT identify at what alias interface ( lan0 or lan0:1 or lan0:2) > > > in which the packet is received. > > > > > > Here the problem is, the relay cannot put its own link local address > > > in the relay address field in the relay forward packet, since this > > > info is useless. > > > > > > The question, SHOULD the relay put the address in lan0:1 (site local > > > address) or lan0:2 (global address)in the relay address field? > > > The DECISION of the relay is very important that depending up on the > > > address it is sending the relay address field only, the server can > > > allocate address to the client. Is there any solution to this > > > problem? > > > ~Vijay > > > > > > > > > > > > ____Vijay_Bhaskar_A_K____ > > > ______Inet_Services______ > > > ________HP_ISO___________ > > > _____Phone:_2051424______ > > > ___Pager:_9624_371137____ > > > > > > > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > http://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > http://www1.ietf.org/mailman/listinfo/dhcwg > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > | Anil Kumar Reddy .S > | Senior Software Engineer, > | Hewlett-Packard, > | Bangalore, INDIA. > | > | Telnet # 847-1426 > | Ph. 2251554 Ext: 1426 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 24 09:02:38 2001 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 JAA01463; Mon, 24 Sep 2001 09:02:37 -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 JAA19945; Mon, 24 Sep 2001 09:00:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19837 for ; Mon, 24 Sep 2001 08:59:52 -0400 (EDT) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00897 for ; Mon, 24 Sep 2001 08:59:44 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id GAA14989 for ; Mon, 24 Sep 2001 06:46:16 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001092323454907120 ; Sun, 23 Sep 2001 23:45:49 -0700 Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T2T6ZZ2P; Sun, 23 Sep 2001 23:46:19 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Sep 2001 08:46:14 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A0247B439@alpha.igk.intel.com> From: "Guja, ArturX" To: "'Ralph Droms'" Cc: "Dhcwg (E-mail)" Subject: RE: [dhcwg] Rebind failure behavior Date: Mon, 24 Sep 2001 08:46:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hello, Thank you for the revised text on REBIND retransmission. I incorporated it in my implementation and it seems to work, as far as the initial testing is concerned. Artur Guja _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 24 09:57:06 2001 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 JAA01468; Mon, 24 Sep 2001 09:02:37 -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 IAA19876; Mon, 24 Sep 2001 08:59:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19819 for ; Mon, 24 Sep 2001 08:59:51 -0400 (EDT) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00868 for ; Mon, 24 Sep 2001 08:59:41 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id IAA07279 for ; Mon, 24 Sep 2001 08:58:11 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001092401574527446 for ; Mon, 24 Sep 2001 01:57:45 -0700 Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T2T6Z53B; Mon, 24 Sep 2001 01:58:15 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Sep 2001 10:58:10 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A0247B446@alpha.igk.intel.com> From: "Guja, ArturX" To: "Dhcwg (E-mail)" Date: Mon, 24 Sep 2001 10:58:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] Re: Rebind failure behavior Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hello, I noticed another bug here: > RT for each subsequent message transmission is based on the previous > value of RT: > > RT = RTprev + RAND*RTprev If RAND is chosen from between -0.1 and 0.1, this certainly cannot be so. I believe it should have read: RT = RTprev * 2 + RAND*RTprev Otherwise, the sequence of RT would fluctuate instead of rising. It could even lead to negative RTs. Artur Guja _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 24 09:57:07 2001 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 JAA01465; Mon, 24 Sep 2001 09:02:37 -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 IAA19812; Mon, 24 Sep 2001 08:59:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19780 for ; Mon, 24 Sep 2001 08:59:49 -0400 (EDT) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00854 for ; Mon, 24 Sep 2001 08:59:39 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id JAA11385 for ; Mon, 24 Sep 2001 09:24:53 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001092402242707319 for ; Mon, 24 Sep 2001 02:24:27 -0700 Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T2T6Z5WF; Mon, 24 Sep 2001 02:24:57 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Sep 2001 11:24:51 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A0247B447@alpha.igk.intel.com> From: "Guja, ArturX" To: "Dhcwg (E-mail)" Date: Mon, 24 Sep 2001 11:24:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" Subject: [dhcwg] Address withdrawal Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hello, I'd like to ask your opinion on the following (standard) scenario: The DHCPv6 client notices, that and address has expired. It proceeds to remove the address from the interface. At the same time, the address was used in as long TCP (or any stream) connection(like a video-conference or file transfer). The address gets removed, the connection breaks down, the user goes mad :))) In the spec, it says that the client should "notify upper layers". So, in real world, what do I do? There is no way I can reassign open application sockets to new addresses. They will break down, won't they? How is this handled? Artur PS: Sorry if this is an idiotic question, but I really have a problem with this. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 24 10:14:49 2001 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 KAA11995; Mon, 24 Sep 2001 10:14:44 -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 KAA23614; Mon, 24 Sep 2001 10:14:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23589 for ; Mon, 24 Sep 2001 10:14:08 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11923 for ; Mon, 24 Sep 2001 10:13:59 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA26777; Mon, 24 Sep 2001 10:13:57 -0400 Date: Mon, 24 Sep 2001 10:13:57 -0400 (EDT) From: Jim Bound To: "Guja, ArturX" Cc: "Dhcwg (E-mail)" Subject: Re: [dhcwg] Address withdrawal In-Reply-To: <413FBB0BA5AED1119122000083234B1A0247B447@alpha.igk.intel.com> Message-Id: 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: X-BeenThere: dhcwg@ietf.org This is real life issue and I point you to the ipv6 stateless code on the implementation your working on. This SHOULD not happen till the address becomes "deprecated". You need to integrate the dhcpv6 client code with the nodes stateless code on your implementation. But there is one issue and that is once an address is truly deprecated the connection is broken. This is not a dhcp issue again but an IPv6 rule. That is why its critical that lifetimes be managed by the server in accordance with the clients needs. But here is a hint and all I have time to do till next week as I got to travel this week shortly to the west coast. In your ipv6 stateless implementation where the code checks for lifetime or event manager based on timers (thats how I designed it on our code base) you now need to add dhcpv6 timers and if-then conditions to that code base to adjust the times for addresses so at renew for dhcpv6 you change the timing of the events to kill a connection at deprecation state. I will bet you have code for ipv6 stateless to do it now you just need to add dhcpv6 affect to that code. I would not rewrite or have separate code for lifetime mgmt for dhcpv6 and stateless but an integrated code base. hope this helps. /jim On Mon, 24 Sep 2001, Guja, ArturX wrote: > Hello, > > I'd like to ask your opinion on the following (standard) scenario: > > The DHCPv6 client notices, that and address has expired. > It proceeds to remove the address from the interface. > At the same time, the address was used in as long TCP > (or any stream) connection(like a video-conference or file > transfer). The address gets removed, the connection breaks > down, the user goes mad :))) > > In the spec, it says that the client should "notify upper layers". > So, in real world, what do I do? There is no way I can > reassign open application sockets to new addresses. They will break > down, won't they? > > How is this handled? > > Artur > > PS: Sorry if this is an idiotic question, but I really have a problem with > this. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 24 15:49:40 2001 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 PAA29104; Mon, 24 Sep 2001 15:49:36 -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 PAA05353; Mon, 24 Sep 2001 15:48:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05330 for ; Mon, 24 Sep 2001 15:48:02 -0400 (EDT) Received: from atlrel6.hp.com (atlrel6.hp.com [192.151.27.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29046 for ; Mon, 24 Sep 2001 15:47:55 -0400 (EDT) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel6.hp.com (Postfix) with ESMTP id 2D2D11F872 for ; Mon, 24 Sep 2001 15:47:29 -0400 (EDT) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id BAA09755 for dhcwg@ietf.org; Tue, 25 Sep 2001 01:21:05 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200109241951.BAA09755@dce.india.hp.com> Subject: Re: [dhcwg] Question on Relay address field To: dhcwg@ietf.org Date: Tue, 25 Sep 2001 01:21:04 +0530 (IST) 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: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Jim, Assume that my relay have the following configuration. lan0 - fe80::260:b0ff:fec1:db08/10 lan0:1 - ff05::1:4:1/64 lan0:2 - 33fe:2900:1::1/64 lan2 - fe80::1/10 lan2:1 - 1234::12/64 Please note that, whether the packet is received in lan0:1 or lan0:2, the stack returns the same interface index. (i.e) the interface index are same for all the logical interfaces like lan0:1, lan0:2,.. Using the IPV6_PKTINFO option in setsockopt(), we can find out ONLY the index of the physical interface. We CANNOT find out the exact alias interface in which it is received. In other words, using the index returned by the IPV6_PKTINFO, we can find out, through which card the packet is received. We can find out whether it is received in lan0 or lan2. But, we cannot find out whether it is received in lan0:1 or lan0:2. This is because, the IPv6 stack assigns a single interface index for each physical interface. Thus in our relay machine configuration... index 1 corresponds to lan0 series. index 2 corresponds to lan2 series. And the API, struct if_nameindex *if_nameindex(void); returns an array of if_nameindex as follows if_index = 1 if_name = lan0 if_index = 2 if_name = lan2 Assume using IPV6_PKTINFO, i am finding out the index as 1. Then using *if_nameindex(void) i am finding out the interface name as "lan0". But the address corresponds to the lan0 is fe80::260:b0ff:fec1:db08/10 (a link local address). This address i SHOULD not put it as the relay address field. Ok, lets us assume that, we will leave the link local addresses of the physical interface, then, SHOULD i choose ff05::1:4:1/64 (lan0:1) (or) 33fe:2900:1::1/64 (lan0:2)? (or) SHOULD i choose always the global address belonging to that physical interface? If we decide that, we will choose always gloabal address, what should i do, if lan0 has 2 global addresses of different prefixes, 3ffe::20/16 and 5fee::20/64? SHOULD i select first one or second one? (or) SHOULD i choose the first configured alias interface in that physical interface? Hope i have explained clearly abt the problem. ~Vijay > Anil, > > OK I get it. Multiple issues here and they are not dhcp issues though. > We in dhcp must assume you can get the interface address it came in on > within an IPv6 implementation and thats not our job here to work that. But > let me try to suggest how I would do it. > > First assume you can get the interface index from 2292-bis or you do it on > your implementation via some other means (sysctl/ioctl). You then do an > if_nameindex() call to get all interface names from the base api not the > advanced api. > > 4.3 Return All Interface Names and Indexes > > The if_nameindex structure holds the information about a single > interface and is defined as a result of including the header. > > struct if_nameindex { > unsigned int if_index; /* 1, 2, ... */ > char *if_name; /* null terminated name: "le0", ... */ > }; > > The final function returns an array of if_nameindex structures, one > structure per interface. > > struct if_nameindex *if_nameindex(void); > > Then we would need to call our implementation defined functions to return > each address for each interface name. > > At this point the relay needs to use the proper scoping to get to the > server. Because we are embedding the address in the relay-forward option > we must do what IPv6 will do with source address selection for sending IP > packets in general which is select the proper scope for the relay-address. > > I would argue until IPv6 scoping is more widely implemented and its not > even been tested at our bake-offs for interoperability just yet the relay > needs to configure a table for each interface at its node and depending on > the scope of the server IP dst address select the best relay-address for > that interface. The default should be a global address for each address > interface at the relay. > > The other thing we can do is add to 2292-bis or build draft in ipng for > extensiion to the base api to return all addresses to if_nameindex(). The > base API is frozen and in the IEEE becoming standard now. So we cannot > change that now or break existing production implementations. > > But I do not think this systems programming implementation issue should > affect the dhcp ipv6 standard at all and we should move forward. This is > an API issue again not dhcpv6 protocol issue. > > And we can all make this work. > > My input to you. > > /jim > > > On Sat, 22 Sep 2001, Anil Kumar Reddy. S wrote: > > > Hi Jim, > > > > As per IPv6 rfc2292bis (draft), through the socket option IPV6_RECVPKTINFO > > we can get the index of the interface through which the client packet is > > received. But the index will be same for all aliases and the > > primary address of the interface. So, if we get the interface index > > and try to get the address of that, then we get the link local address only > > > > because the primary address of an interface is always link local. > > ( Hope, I am clear in explaining ;-)) ) > > > > In this case, how the relay is expected to work, when an interface > > is configured with the addresses given by Vijay ?? Which address it has > > to consider ?? > > > > - Anil > > > > Jim Bound wrote: > > > > > Vijay, > > > > > > I am not clear why you can't tell the alias. This will be a function of > > > the scoping code for IPv6 as the interface in your example is using > > > scoping (your aliases) and that is code that would have to be part of the > > > base IPv6 stack to return from the API index routines? > > > > > > I am not clear this is a dhcp problem but an IPv6 implementation problem > > > in general we all are working on now? > > > > > > Maybe I am missing your issue though? > > > > > > thanks > > > > > > /jim > > > > > > On Fri, 21 Sep 2001, Vijay Bhaskar A K wrote: > > > > > > > The latest draft on DHCPv6 says that, the client sends the > > > > request to All Agents multicast address. The Agents put its > > > > own address of the interface in which the client packet is > > > > recieved, in the Relay-forward packet. > > > > > > > > Assume the configuration one of the interface of the Agent is as follows. > > > > > > > > lan0 - A link local address > > > > lan0:1 - A site local address > > > > lan0:2 - A gloabal address > > > > > > > > Assume the packet is received from the client in the lan0 interface of the > > > > agent. > > > > Using our latest IPv6 APIs, we can identify this. > > > > But, we CANT identify at what alias interface ( lan0 or lan0:1 or lan0:2) > > > > in which the packet is received. > > > > > > > > Here the problem is, the relay cannot put its own link local address > > > > in the relay address field in the relay forward packet, since this > > > > info is useless. > > > > > > > > The question, SHOULD the relay put the address in lan0:1 (site local > > > > address) or lan0:2 (global address)in the relay address field? > > > > The DECISION of the relay is very important that depending up on the > > > > address it is sending the relay address field only, the server can > > > > allocate address to the client. Is there any solution to this > > > > problem? > > > > ~Vijay > > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 24 16:19:50 2001 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 QAA29808; Mon, 24 Sep 2001 16:19:49 -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 QAA06336; Mon, 24 Sep 2001 16:19:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06312 for ; Mon, 24 Sep 2001 16:19:10 -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 QAA29729 for ; Mon, 24 Sep 2001 16:19:01 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-229.ip.theriver.com [205.140.116.229]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f8OJojv20504; Mon, 24 Sep 2001 12:50:45 -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 f8OKF9Z02431; Mon, 24 Sep 2001 13:15:09 -0700 (MST) Message-Id: <200109242015.f8OKF9Z02431@grosse.bisbee.fugue.com> To: Vijay Bhaskar A K cc: dhcwg@ietf.org Subject: Re: [dhcwg] Question on Relay address field In-Reply-To: Message from Vijay Bhaskar A K of "Tue, 25 Sep 2001 01:21:04 +0530." <200109241951.BAA09755@dce.india.hp.com> Date: Mon, 24 Sep 2001 13:15:09 -0700 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Using the IPV6_PKTINFO option in setsockopt(), we can find out ONLY the > index of the physical interface. We CANNOT find out the exact alias > interface in which it is received. Packets are not received by interface aliases - they are received by interfaces. There is no way that IPV6_PKTINFO *could* tell you on which alias interface a packet was received, because interface aliases are not hardware - they are merely a logical construct that is used to hang more than one address onto a single physical interface. So there is no way to make the determination you're talking about - a packet arrives on an interface, and any kind of processing you want to apply to it beyond that has to be done in your software. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 24 18:53:13 2001 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 SAA02922; Mon, 24 Sep 2001 18:53:12 -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 SAA10287; Mon, 24 Sep 2001 18:52:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10262 for ; Mon, 24 Sep 2001 18:52:18 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02885 for ; Mon, 24 Sep 2001 18:52:10 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f8OMplQ09473 for ; Mon, 24 Sep 2001 17:51:47 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8OMplW16361 for ; Mon, 24 Sep 2001 17:51:47 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Sep 24 17:43:24 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 22 Sep 2001 12:46:46 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3651@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Jim Bound'" , "Anil Kumar Reddy. S" Cc: "Dhcwg (E-mail)" Subject: RE: [dhcwg] Question on Relay address field Date: Sat, 22 Sep 2001 12:46:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1438E.8C175180" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1438E.8C175180 Content-Type: text/plain; charset="iso-8859-1" Note that recent changes for the -20 text address this in two ways: 1) The address given to the server is used to determine the link on which the client is located. This really (IMHO) should be a global address. But, I would recommend that relay implementors allow this to be set for a link (as to which address should be used). By default, I agree with Jim - use the/a global address. 2) If a relay needs specific information that it cannot communicate simply by supplying the address, we have added a relay option where it can pass the server anything it wants to use to identify how the relay needs to return the packet to the client. This information is sent back by the server in the Relay-Reply. And, as Jim commented, this isn't really just a DHCP issue - it is more of a network issue in general. But if a particular implementation has a way to solve it, DHCPv6 is OK because it can be used to pass it on (such that the relay can return the reply). - Bernie Volz -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Saturday, September 22, 2001 12:53 PM To: Anil Kumar Reddy. S Cc: Dhcwg (E-mail) Subject: Re: [dhcwg] Question on Relay address field Anil, OK I get it. Multiple issues here and they are not dhcp issues though. We in dhcp must assume you can get the interface address it came in on within an IPv6 implementation and thats not our job here to work that. But let me try to suggest how I would do it. First assume you can get the interface index from 2292-bis or you do it on your implementation via some other means (sysctl/ioctl). You then do an if_nameindex() call to get all interface names from the base api not the advanced api. 4.3 Return All Interface Names and Indexes The if_nameindex structure holds the information about a single interface and is defined as a result of including the header. struct if_nameindex { unsigned int if_index; /* 1, 2, ... */ char *if_name; /* null terminated name: "le0", ... */ }; The final function returns an array of if_nameindex structures, one structure per interface. struct if_nameindex *if_nameindex(void); Then we would need to call our implementation defined functions to return each address for each interface name. At this point the relay needs to use the proper scoping to get to the server. Because we are embedding the address in the relay-forward option we must do what IPv6 will do with source address selection for sending IP packets in general which is select the proper scope for the relay-address. I would argue until IPv6 scoping is more widely implemented and its not even been tested at our bake-offs for interoperability just yet the relay needs to configure a table for each interface at its node and depending on the scope of the server IP dst address select the best relay-address for that interface. The default should be a global address for each address interface at the relay. The other thing we can do is add to 2292-bis or build draft in ipng for extensiion to the base api to return all addresses to if_nameindex(). The base API is frozen and in the IEEE becoming standard now. So we cannot change that now or break existing production implementations. But I do not think this systems programming implementation issue should affect the dhcp ipv6 standard at all and we should move forward. This is an API issue again not dhcpv6 protocol issue. And we can all make this work. My input to you. /jim On Sat, 22 Sep 2001, Anil Kumar Reddy. S wrote: > Hi Jim, > > As per IPv6 rfc2292bis (draft), through the socket option IPV6_RECVPKTINFO > we can get the index of the interface through which the client packet is > received. But the index will be same for all aliases and the > primary address of the interface. So, if we get the interface index > and try to get the address of that, then we get the link local address only > > because the primary address of an interface is always link local. > ( Hope, I am clear in explaining ;-)) ) > > In this case, how the relay is expected to work, when an interface > is configured with the addresses given by Vijay ?? Which address it has > to consider ?? > > - Anil > > Jim Bound wrote: > > > Vijay, > > > > I am not clear why you can't tell the alias. This will be a function of > > the scoping code for IPv6 as the interface in your example is using > > scoping (your aliases) and that is code that would have to be part of the > > base IPv6 stack to return from the API index routines? > > > > I am not clear this is a dhcp problem but an IPv6 implementation problem > > in general we all are working on now? > > > > Maybe I am missing your issue though? > > > > thanks > > > > /jim > > > > On Fri, 21 Sep 2001, Vijay Bhaskar A K wrote: > > > > > The latest draft on DHCPv6 says that, the client sends the > > > request to All Agents multicast address. The Agents put its > > > own address of the interface in which the client packet is > > > recieved, in the Relay-forward packet. > > > > > > Assume the configuration one of the interface of the Agent is as follows. > > > > > > lan0 - A link local address > > > lan0:1 - A site local address > > > lan0:2 - A gloabal address > > > > > > Assume the packet is received from the client in the lan0 interface of the > > > agent. > > > Using our latest IPv6 APIs, we can identify this. > > > But, we CANT identify at what alias interface ( lan0 or lan0:1 or lan0:2) > > > in which the packet is received. > > > > > > Here the problem is, the relay cannot put its own link local address > > > in the relay address field in the relay forward packet, since this > > > info is useless. > > > > > > The question, SHOULD the relay put the address in lan0:1 (site local > > > address) or lan0:2 (global address)in the relay address field? > > > The DECISION of the relay is very important that depending up on the > > > address it is sending the relay address field only, the server can > > > allocate address to the client. Is there any solution to this > > > problem? > > > ~Vijay > > > > > > > > > > > > ____Vijay_Bhaskar_A_K____ > > > ______Inet_Services______ > > > ________HP_ISO___________ > > > _____Phone:_2051424______ > > > ___Pager:_9624_371137____ > > > > > > > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > http://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > http://www1.ietf.org/mailman/listinfo/dhcwg > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > | Anil Kumar Reddy .S > | Senior Software Engineer, > | Hewlett-Packard, > | Bangalore, INDIA. > | > | Telnet # 847-1426 > | Ph. 2251554 Ext: 1426 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1438E.8C175180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Question on Relay address field

Note that recent changes for the -20 text address = this in two ways:

1) The address given to the server is used to = determine the link on which the client is located. This really (IMHO) = should be a global address. But, I would recommend that relay = implementors allow this to be set for a link (as to which address = should be used). By default, I agree with Jim - use the/a global = address.

2) If a relay needs specific information that it = cannot communicate simply by supplying the address, we have added a = relay option where it can pass the server anything it wants to use to = identify how the relay needs to return the packet to the client. This = information is sent back by the server in the Relay-Reply.

And, as Jim commented, this isn't really just a DHCP = issue - it is more of a network issue in general. But if a particular = implementation has a way to solve it, DHCPv6 is OK because it can be = used to pass it on (such that the relay can return the = reply).

- Bernie Volz

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]=
Sent: Saturday, September 22, 2001 12:53 PM
To: Anil Kumar Reddy. S
Cc: Dhcwg (E-mail)
Subject: Re: [dhcwg] Question on Relay address = field


Anil,

OK I get it.  Multiple issues here and they are = not dhcp issues though.
We in dhcp must assume you can get the interface = address it came in on
within an IPv6 implementation and thats not our job = here to work that. But
let me try to suggest how I would do it.

First assume you can get the interface index from = 2292-bis or you do it on
your implementation via some other means = (sysctl/ioctl).  You then do an
if_nameindex() call to get all interface names from = the base api not the
advanced api.

4.3 Return All Interface Names and Indexes

The if_nameindex structure holds the information = about a single
interface and is defined as a result of including = the <net/if.h> header.

   struct if_nameindex {
     unsigned int   = if_index;  /* 1, 2, ... */
     = char          = *if_name;   /* null terminated name: "le0", ... = */
   };

The final function returns an array of if_nameindex = structures, one
structure per interface.

   struct if_nameindex  = *if_nameindex(void);

Then we would need to call our implementation defined = functions to return
each address for each interface name.

At this point the relay needs to use the proper = scoping to get to the
server.  Because we are embedding the address = in the relay-forward option
we must do what IPv6 will do with source address = selection for sending IP
packets in general which is select the proper scope = for the relay-address.

I would argue until IPv6 scoping is more widely = implemented and its not
even been tested at our bake-offs for = interoperability just yet the relay
needs to configure a table for each interface at its = node and depending on
the scope of the server IP dst address select the = best relay-address for
that interface.  The default should be a global = address for each address
interface at the relay.

The other thing we can do is add to 2292-bis or build = draft in ipng for
extensiion to the base api to return all addresses = to if_nameindex(). The
base API is frozen and in the IEEE becoming standard = now. So we cannot
change that now or break existing production = implementations.

But I do not think this systems programming = implementation issue should
affect the dhcp ipv6 standard at all and we should = move forward. This is
an API issue again not dhcpv6 protocol issue.

And we can all make this work.

My input to you.

/jim


On Sat, 22 Sep 2001, Anil Kumar Reddy. S = wrote:

> Hi Jim,
>
>     As per IPv6 rfc2292bis = (draft), through the socket option IPV6_RECVPKTINFO
>     we can get the index of = the interface through which the client packet is
>     received. But the index = will be same for all aliases and the
>     primary address of the = interface. So, if we get the interface index
>     and try to get the = address of that, then we get the link local address only
>
>     because the primary = address of an interface is always link local.
>     (  Hope, I am = clear in explaining   ;-))  )
>
>     In this case, how the = relay is expected to work, when an interface
>     is configured with the = addresses given by Vijay ?? Which address it has
>     to consider ??
>
> - Anil
>
> Jim Bound wrote:
>
> > Vijay,
> >
> > I am not clear why you can't tell the = alias.  This will be a function of
> > the scoping code for IPv6 as the interface = in your example is using
> > scoping (your aliases) and that is code = that would have to be part of the
> > base IPv6 stack to return from the API = index routines?
> >
> > I am not clear this is a dhcp problem but = an IPv6 implementation problem
> > in general we all are working on = now?
> >
> > Maybe I am missing your issue = though?
> >
> > thanks
> >
> > /jim
> >
> > On Fri, 21 Sep 2001, Vijay Bhaskar A K = wrote:
> >
> > > The latest draft on DHCPv6 says that, = the client sends the
> > > request to All Agents multicast = address. The Agents put its
> > > own address of the interface in which = the client packet is
> > > recieved, in the Relay-forward = packet.
> > >
> > > Assume the configuration one of the = interface of the Agent is as follows.
> > >
> > > lan0   -  A link local = address
> > > lan0:1 -  A site local = address
> > > lan0:2 -  A gloabal = address
> > >
> > > Assume the packet is received from = the client in the lan0 interface of the
> > > agent.
> > > Using our latest IPv6 APIs, we can = identify this.
> > > But, we CANT identify at what alias = interface ( lan0 or lan0:1 or lan0:2)
> > > in which the packet is = received.
> > >
> > > Here the problem is, the relay cannot = put its own link local address
> > > in the relay address field in the = relay forward packet, since this
> > > info is useless.
> > >
> > > The question, SHOULD the relay put = the address in lan0:1 (site local
> > > address) or lan0:2 (global address)in = the relay address field?
> > > The DECISION of the relay is very = important that depending up on the
> > > address it is sending the relay = address field only, the server can
> > > allocate address to the client. Is = there any solution to this
> > > problem?
> > > ~Vijay
> > >
> > >
> > >
> > > ____Vijay_Bhaskar_A_K____
> > > ______Inet_Services______
> > > ________HP_ISO___________
> > > _____Phone:_2051424______
> > > ___Pager:_9624_371137____
> > >
> > >
> > > = _______________________________________________
> > > dhcwg mailing list
> > > dhcwg@ietf.org
> > > http://www1.ietf.org/mailman/listinfo/dhcwg=
> > >
> >
> > = _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > http://www1.ietf.org/mailman/listinfo/dhcwg=
>
> --
> = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
> |  Anil Kumar Reddy .S
> |  Senior Software Engineer,
> |  Hewlett-Packard,
> |  Bangalore, INDIA.
> |
> |  Telnet # 847-1426
> |  Ph. 2251554 Ext: 1426
> = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
>
>
>


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

------_=_NextPart_001_01C1438E.8C175180-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 24 18:55:27 2001 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 SAA02981; Mon, 24 Sep 2001 18:55:27 -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 SAA10383; Mon, 24 Sep 2001 18:54:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10315 for ; Mon, 24 Sep 2001 18:54:53 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02966 for ; Mon, 24 Sep 2001 18:54:45 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f8OMsMQ11609 for ; Mon, 24 Sep 2001 17:54:22 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8OMsMW19032 for ; Mon, 24 Sep 2001 17:54:22 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Sep 24 17:43:30 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 22 Sep 2001 12:51:35 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3653@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Jim Bound'" , "Guja, ArturX" Cc: "Dhcwg (E-mail)" Subject: RE: [dhcwg] Implementation problem Date: Sat, 22 Sep 2001 12:51:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1438F.384D2A10" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1438F.384D2A10 Content-Type: text/plain; charset="iso-8859-1" My understanding is that the server always provides a fully specified 128-bit IPv6 address. If we ever want to just assign prefixes, we always can define a new option for that purpose. -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Friday, September 21, 2001 11:55 PM To: Guja, ArturX Cc: Dhcwg (E-mail) Subject: Re: [dhcwg] Implementation problem We have gone back and forth on this. I am assuming we are now at the state where you use it as-is? I believe that was consensus of last round? If we don't do this it gets too complicated to finish this spec for last call. In the future we can extend address types and scenarios. /jim On Fri, 21 Sep 2001, Guja, ArturX wrote: > Can a client get ANY address from the available pools, > or does it only get a prefix to be filled with its interface identifier? > > Or, is it the server's duty to make sure, that the addresses passed > to the client are of the form: > prefix + interface ID > If so, the server could take the interface ID of the client from the > client's > link local address (if it still gets it, I'm not sure after all the changes > here). > > Does the client check the addresses' structure, or does it assign those > addresses to its interfaces on an "AS IS" principle? > > Artur G. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1438F.384D2A10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Implementation problem

My understanding is that the server always provides a = fully specified 128-bit IPv6 address.

If we ever want to just assign prefixes, we always = can define a new option for that purpose.

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]=
Sent: Friday, September 21, 2001 11:55 PM
To: Guja, ArturX
Cc: Dhcwg (E-mail)
Subject: Re: [dhcwg] Implementation problem


We have gone back and forth on this.  I am = assuming we are now at the
state where you use it as-is?  I believe that = was consensus of last round?
If we don't do this it gets too complicated to = finish this spec for last
call.  In the future we can extend address = types and scenarios. 


/jim


On Fri, 21 Sep 2001, Guja, ArturX wrote:

> Can a client get ANY address from the available = pools,
> or does it only get a prefix to be filled with = its interface identifier?
>
> Or, is it the server's duty to make sure, that = the addresses passed
> to the client are of the form:
> prefix + interface ID
> If so, the server could take the interface ID = of the client from the
> client's
> link local address (if it still gets it, I'm = not sure after all the changes
> here).
>
> Does the client check the addresses' structure, = or does it assign those
> addresses to its interfaces on an "AS = IS" principle?
>
> Artur G.
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> http://www1.ietf.org/mailman/listinfo/dhcwg=
>


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

------_=_NextPart_001_01C1438F.384D2A10-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 25 08:15:46 2001 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 IAA29049; Tue, 25 Sep 2001 08:15:42 -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 IAA05686; Tue, 25 Sep 2001 08:15:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05662 for ; Tue, 25 Sep 2001 08:15:04 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29034 for ; Tue, 25 Sep 2001 08:14:59 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn2-117.cisco.com [10.21.112.117]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA07357 for ; Tue, 25 Sep 2001 08:14:31 -0400 (EDT) Message-Id: <4.3.2.7.2.20010925080039.00b6a270@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Sep 2001 08:14:04 -0400 To: "Dhcwg (E-mail)" From: Ralph Droms Subject: RE: [dhcwg] Question on Relay address field In-Reply-To: <66F66129A77AD411B76200508B65AC697B3651@eambunt705.ena-east .ericsson.se> 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: X-BeenThere: dhcwg@ietf.org Let me see if I can successfully summarize the issues and give my review: Protocol specification - we need to make clear that the specification for the relay agent allows for the relay agent to use any of its addresses assigned to the same link as the client is attached. The current text from the -20 rev is, IMHO, almost right: 17.1. Relaying of client messages When a Relay receives a valid client message, it constructs a Relay-forward message. The relay places an address with a prefix assigned to the link on which the client should be assigned an address in the link-prefix field. This address will be used by the server to determine the link from which the client should be assigned an address and other configuration information. I was about to suggest a clarification to edit the second sentence to begin: "The relay places one of its own addresses with a prefix..." But, I don't think that's necessary - the address in the link-prefix field doesn't even need to belong to the relay. All that's required is that the prefix of the address be assigned to the right link. Implementability - we need to make sure that what we've specified in section 17.1 is actually implementable. If we agree that the text in 17.1 is OK, then there is no *requirement* that the address be selected from the addresses assigned to the interfaces. All that's required is that the relay agent have some way to pick an appropriate address for each inbound message from a client. Implementors may choose to use some static configuration, independent of interface addresses, or may choose to develop a list at initialization in the relay agent through the interface API, or may choose to look up the list of addresses dynamically (again through the interface API) as each message is received. If we agree that the current text in 17.1 (rev -20) is implementable, we can leave the text unchanged... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 25 11:46:44 2001 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 LAA07029; Tue, 25 Sep 2001 11:46:44 -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 LAA12429; Tue, 25 Sep 2001 11:45:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12397 for ; Tue, 25 Sep 2001 11:45:00 -0400 (EDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07003 for ; Tue, 25 Sep 2001 11:44:56 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel11.hp.com (Postfix) with ESMTP id 5F8721F555 for ; Tue, 25 Sep 2001 08:44:25 -0700 (PDT) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id VAA19483 for ; Tue, 25 Sep 2001 21:10:59 +0530 (IST) Reply-To: From: "Vijay Bhaskar A K" To: "Dhcwg (E-mail)" Subject: RE: [dhcwg] Question on Relay address field Date: Tue, 25 Sep 2001 21:14:23 +0530 Message-ID: <001d01c145d8$f35019d0$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <001c01c145d8$5c877c00$2f290a0f@india.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On > Behalf Of Bernie > Volz (EUD) > Sent: Saturday, September 22, 2001 11:17 PM > To: 'Jim Bound'; Anil Kumar Reddy. S > Cc: Dhcwg (E-mail) > Subject: RE: [dhcwg] Question on Relay address field > > > Note that recent changes for the -20 text address this in two ways: > 1) The address given to the server is used to determine the > link on which > the client is located. This really (IMHO) should be a global > address. But, I > would recommend that relay implementors allow this to be set > for a link (as > to which address should be used). By default, I agree with > Jim - use the/a > global address. The question here is, a) If there are two global addresses of different subnet prefix in that interface, what address it has to choose? b) If there is no global address in that interface, can the relay choose a site-local address? > 2) If a relay needs specific information that it cannot > communicate simply > by supplying the address, we have added a relay option where > it can pass the > server anything it wants to use to identify how the relay > needs to return > the packet to the client. This information is sent back by > the server in the > Relay-Reply. > And, as Jim commented, this isn't really just a DHCP issue - > it is more of a > network issue in general. But if a particular implementation > has a way to > solve it, DHCPv6 is OK because it can be used to pass it on > (such that the > relay can return the reply). > - Bernie Volz > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Saturday, September 22, 2001 12:53 PM > To: Anil Kumar Reddy. S > Cc: Dhcwg (E-mail) > Subject: Re: [dhcwg] Question on Relay address field > > > Anil, > OK I get it. Multiple issues here and they are not dhcp > issues though. > We in dhcp must assume you can get the interface address it came in on > within an IPv6 implementation and thats not our job here to > work that. But > let me try to suggest how I would do it. > First assume you can get the interface index from 2292-bis or > you do it on > your implementation via some other means (sysctl/ioctl). You > then do an > if_nameindex() call to get all interface names from the base > api not the > advanced api. > 4.3 Return All Interface Names and Indexes > The if_nameindex structure holds the information about a single > interface and is defined as a result of including the > header. > struct if_nameindex { > unsigned int if_index; /* 1, 2, ... */ > char *if_name; /* null terminated name: "le0", ... */ > }; > The final function returns an array of if_nameindex structures, one > structure per interface. > struct if_nameindex *if_nameindex(void); > Then we would need to call our implementation defined > functions to return > each address for each interface name. > At this point the relay needs to use the proper scoping to get to the > server. Because we are embedding the address in the > relay-forward option > we must do what IPv6 will do with source address selection > for sending IP > packets in general which is select the proper scope for the > relay-address. > I would argue until IPv6 scoping is more widely implemented > and its not > even been tested at our bake-offs for interoperability just > yet the relay > needs to configure a table for each interface at its node and > depending on > the scope of the server IP dst address select the best > relay-address for > that interface. The default should be a global address for > each address > interface at the relay. > The other thing we can do is add to 2292-bis or build draft > in ipng for > extensiion to the base api to return all addresses to > if_nameindex(). The > base API is frozen and in the IEEE becoming standard now. So we cannot > change that now or break existing production implementations. > But I do not think this systems programming implementation > issue should > affect the dhcp ipv6 standard at all and we should move > forward. This is > an API issue again not dhcpv6 protocol issue. > And we can all make this work. > My input to you. > /jim > > > On Sat, 22 Sep 2001, Anil Kumar Reddy. S wrote: > > Hi Jim, > > > > As per IPv6 rfc2292bis (draft), through the socket option > IPV6_RECVPKTINFO > > we can get the index of the interface through which the > client packet > is > > received. But the index will be same for all aliases and the > > primary address of the interface. So, if we get the > interface index > > and try to get the address of that, then we get the > link local address > only > > > > because the primary address of an interface is always > link local. > > ( Hope, I am clear in explaining ;-)) ) > > > > In this case, how the relay is expected to work, when > an interface > > is configured with the addresses given by Vijay ?? > Which address it > has > > to consider ?? > > > > - Anil > > > > Jim Bound wrote: > > > > > Vijay, > > > > > > I am not clear why you can't tell the alias. This will > be a function of > > > the scoping code for IPv6 as the interface in your > example is using > > > scoping (your aliases) and that is code that would have > to be part of > the > > > base IPv6 stack to return from the API index routines? > > > > > > I am not clear this is a dhcp problem but an IPv6 > implementation problem > > > in general we all are working on now? > > > > > > Maybe I am missing your issue though? > > > > > > thanks > > > > > > /jim > > > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 25 12:25:37 2001 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 MAA08267; Tue, 25 Sep 2001 12:25:37 -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 MAA14820; Tue, 25 Sep 2001 12:25:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14794 for ; Tue, 25 Sep 2001 12:25:04 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08260 for ; Tue, 25 Sep 2001 12:24:57 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-196.cisco.com [161.44.149.196]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA08092 for ; Tue, 25 Sep 2001 12:24:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20010925122039.00b71b30@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Sep 2001 12:24:04 -0400 To: "Dhcwg (E-mail)" From: Ralph Droms Subject: RE: [dhcwg] Question on Relay address field In-Reply-To: <001d01c145d8$f35019d0$2f290a0f@india.hp.com> References: <001c01c145d8$5c877c00$2f290a0f@india.hp.com> 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: X-BeenThere: dhcwg@ietf.org Good questions - here are my answers: a) Doesn't matter - DHCP server MUST be configured with enough architecture information to be able to map any address to a link b) Same answer - DHCP server MUST know site-local addresses to do the address->link mapping Perhaps there's a need to include a few words explaining about what the DHCP server MUST know about... - Ralph At 09:14 PM 9/25/2001 +0530, Vijay Bhaskar A K wrote: >The question here is, >a) If there are two global addresses of different subnet >prefix in that interface, what address it has to choose? >b) If there is no global address in that interface, can >the relay choose a site-local address? _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 25 12:33:38 2001 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 MAA08601; Tue, 25 Sep 2001 12:33:38 -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 MAA15386; Tue, 25 Sep 2001 12:32:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15362 for ; Tue, 25 Sep 2001 12:32:49 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08566 for ; Tue, 25 Sep 2001 12:32:44 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f8PGWm715372 for ; Tue, 25 Sep 2001 11:32:48 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8PGWl119568 for ; Tue, 25 Sep 2001 11:32:47 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Sep 25 11:32:47 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Sep 2001 11:32:47 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69904670@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: Ralph Droms , "Dhcwg (E-mail)" Subject: RE: [dhcwg] Question on Relay address field Date: Tue, 25 Sep 2001 11:32:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C145DF.B5191CF0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C145DF.B5191CF0 Content-Type: text/plain; charset="iso-8859-1" I think it is fine to leave the text in 17.1 as is. The address does need to be meaningful to the DHCP server but that is made clear in the third sentence. - Bernie ------_=_NextPart_001_01C145DF.B5191CF0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Question on Relay address field

I think it is fine to leave the text in 17.1 as is.

The address does need to be meaningful to the DHCP server but that is made clear in the third sentence.

- Bernie

------_=_NextPart_001_01C145DF.B5191CF0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 25 12:38:40 2001 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 MAA08787; Tue, 25 Sep 2001 12:38:40 -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 MAA15529; Tue, 25 Sep 2001 12:36:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15504 for ; Tue, 25 Sep 2001 12:36:32 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08716 for ; Tue, 25 Sep 2001 12:36:29 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f8PGaV718389 for ; Tue, 25 Sep 2001 11:36:31 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8PGaVu04348 for ; Tue, 25 Sep 2001 11:36:31 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Sep 25 11:36:30 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Sep 2001 11:36:30 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B367A@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , "Dhcwg (E-mail)" Subject: RE: [dhcwg] Question on Relay address field Date: Tue, 25 Sep 2001 11:36:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C145E0.3A65DE70" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C145E0.3A65DE70 Content-Type: text/plain; charset="iso-8859-1" I don't think that DHCP servers need necessary know all of the architecture information. They and the relays must be configured appropriately such that the relays provide the DHCP server(s) the correct information. In the particular cases mentioned, I agree with Ralph. In a either address should work. In b, the site-local is all that can be used. I think it best we specify that a relay should be configureable to return specific information and if it hasn't been configured, it should use the most "global" information it has (either a global address or site-local). It can't use link-local addresses. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, September 25, 2001 12:24 PM To: Dhcwg (E-mail) Subject: RE: [dhcwg] Question on Relay address field Good questions - here are my answers: a) Doesn't matter - DHCP server MUST be configured with enough architecture information to be able to map any address to a link b) Same answer - DHCP server MUST know site-local addresses to do the address->link mapping Perhaps there's a need to include a few words explaining about what the DHCP server MUST know about... - Ralph At 09:14 PM 9/25/2001 +0530, Vijay Bhaskar A K wrote: >The question here is, >a) If there are two global addresses of different subnet >prefix in that interface, what address it has to choose? >b) If there is no global address in that interface, can >the relay choose a site-local address? _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C145E0.3A65DE70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Question on Relay address field

I don't think that DHCP servers need necessary know = all of the architecture information. They and the relays must be = configured appropriately such that the relays provide the DHCP = server(s) the correct information.

In the particular cases mentioned, I agree with = Ralph. In a either address should work. In b, the site-local is all = that can be used.

I think it best we specify that a relay should be = configureable to return specific information and if it hasn't been = configured, it should use the most "global" information it = has (either a global address or site-local). It can't use link-local = addresses.

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, September 25, 2001 12:24 PM
To: Dhcwg (E-mail)
Subject: RE: [dhcwg] Question on Relay address = field


Good questions - here are my answers:

a) Doesn't matter - DHCP server MUST be configured = with
    enough architecture information = to be able to map
    any address to a link
b) Same answer - DHCP server MUST know = site-local
    addresses to do the = address->link mapping

Perhaps there's a need to include a few words = explaining
about what the DHCP server MUST know about...

- Ralph

At 09:14 PM 9/25/2001 +0530, Vijay Bhaskar A K = wrote:

>The question here is,
>a) If there are two global addresses of = different subnet
>prefix in that interface, what address it has to = choose?
>b) If there is no global address in that = interface, can
>the relay choose a site-local address?





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

------_=_NextPart_001_01C145E0.3A65DE70-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 01:01:14 2001 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 BAA24785; Wed, 26 Sep 2001 01:01:14 -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 AAA08383; Wed, 26 Sep 2001 00:51:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA08355 for ; Wed, 26 Sep 2001 00:51:18 -0400 (EDT) Received: from internaut.com ([64.38.134.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24700 for ; Wed, 26 Sep 2001 00:51:17 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id VAA25132; Tue, 25 Sep 2001 21:43:15 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 25 Sep 2001 21:43:14 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org cc: narten@raleigh.ibm.com In-Reply-To: <66F66129A77AD411B76200508B65AC697B35F4@eambunt705.ena-east.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Incorporation of WG last call comments in draft-aboba-dhc-domsearch-06.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org WG last call comments on draft-aboba-dhc-domsearch-05.txt have been incorporated into draft-aboba-dhc-domsearch-06.txt, which is now on the IETF archive. Now that these comments have been incorporated, I believe that this document is ready for IETF last call. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 07:14:04 2001 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 HAA12986; Wed, 26 Sep 2001 07:14:04 -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 HAA24123; Wed, 26 Sep 2001 07:05:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24098 for ; Wed, 26 Sep 2001 07:05:11 -0400 (EDT) Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12458 for ; Wed, 26 Sep 2001 07:05:09 -0400 (EDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id f8QB27P04976; Wed, 26 Sep 2001 07:02:07 -0400 Message-Id: <200109261102.f8QB27P04976@hygro.adsl.duke.edu> To: Bernard Aboba cc: dhcwg@ietf.org Subject: Re: [dhcwg] Incorporation of WG last call comments in draft-aboba-dhc-domsearch-06.txt In-Reply-To: Message from "Tue, 25 Sep 2001 21:43:14 PDT." Date: Wed, 26 Sep 2001 07:02:07 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Now that these comments have been incorporated, I believe that this > document is ready for IETF last call. I'll wait for Ralph to signal that the document is ready, but here are my comments. Main item is that it has a normative reference to > [7] Lemon, T., "Encoding Long DHCP Options", Internet draft (work in > progress), draft-ietf-dhc-concat-01.txt, July 2001. so these two document should go together. Some minor wording nits (these can be dealt with later): > the domain search list. This document defines a new DHCP option which > is passed from the DHCP Server to the DHCP Client to specify the domain > search list when resolving hostnames. Is the option allowed to be included in client messages? I would assume so. Indeed, isn't it the case that clients can include any option if to signal a desire to the server to get such an option returned? If so, I guess this isn't really an issue. > In this scheme, an entire domain name or a list of labels at the end of > a domain name is replaced with a pointer to a prior occurrence of the s/is replaced/can be replaced/ > same name. Despite its complexity, this technique is valuable since the Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 10:14:17 2001 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 KAA19759; Wed, 26 Sep 2001 10:14:17 -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 KAA00443; Wed, 26 Sep 2001 10:13:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00418 for ; Wed, 26 Sep 2001 10:13:19 -0400 (EDT) Received: from internaut.com ([64.38.134.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19715 for ; Wed, 26 Sep 2001 10:13:15 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA25805; Wed, 26 Sep 2001 07:00:14 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 26 Sep 2001 07:00:14 -0700 (PDT) From: Bernard Aboba To: Thomas Narten cc: dhcwg@ietf.org Subject: Re: [dhcwg] Incorporation of WG last call comments in draft-aboba-dhc-domsearch-06.txt In-Reply-To: <200109261102.f8QB27P04976@hygro.adsl.duke.edu> Message-ID: 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: X-BeenThere: dhcwg@ietf.org > Main item is that it has a normative reference to > > > [7] Lemon, T., "Encoding Long DHCP Options", Internet draft (work in > > progress), draft-ietf-dhc-concat-01.txt, July 2001. > > so these two document should go together. Not sure the reference is normative. This option can use the long option encoding if available, but doesn't require it. > > Some minor wording nits (these can be dealt with later): > > > the domain search list. This document defines a new DHCP option which > > is passed from the DHCP Server to the DHCP Client to specify the domain > > search list when resolving hostnames. > > Is the option allowed to be included in client messages? I would > assume so. Indeed, isn't it the case that clients can include any > option if to signal a desire to the server to get such an option > returned? If so, I guess this isn't really an issue. Yes, that's my understanding. > > > In this scheme, an entire domain name or a list of labels at the end of > > a domain name is replaced with a pointer to a prior occurrence of the > > s/is replaced/can be replaced/ > > > same name. Despite its complexity, this technique is valuable since the > > Thomas > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 10:32:44 2001 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 KAA20088; Wed, 26 Sep 2001 10:32:44 -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 KAA01111; Wed, 26 Sep 2001 10:31:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01086 for ; Wed, 26 Sep 2001 10:31:47 -0400 (EDT) Received: from extmail01m.raleigh.ibm.com (extmail01.raleigh.ibm.com [204.146.167.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20075 for ; Wed, 26 Sep 2001 10:31:44 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [192.168.1.109]) by extmail01m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id KAA24252 for ; Wed, 26 Sep 2001 10:31:15 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id KAA29742 for ; Wed, 26 Sep 2001 10:31:14 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id KAA15509 for ; Wed, 26 Sep 2001 10:29:18 -0400 Message-Id: <200109261429.KAA15509@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 26 Sep 2001 10:29:18 -0400 From: Thomas Narten Subject: [dhcwg] draft-ietf-dhc-concat-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Given that draft-aboba-dhc-domsearch-06.txt needs this document, I went ahead and had a look at it. Here are my comments. Thomas Major issue: The document goes to great lengths to NOT make existing clients/servers out of spec with this ID. This seems misguided. Most RFCs define new behavior. That existing implementations don't follow the RFC is not a problem. Indeed, the goal is to make sure all future implementations (or updates to existing implementations) adhere to the new spec. But the current document includes language that seems to suggest existing implementations are already compliant, hence they need not be updated. In that case, what is the point of doing this? I cite a number of wording issues below, that have to do with this issue. I.e., the document should make it clear what the desired wording should be, rather than trying to just encourage the behavior while still (from a requirements perspective) saying it's not really required. Detailed comments: The document should say in the introduction that it updates RFC XXX (the base DHCP spec). We specify here an ordering that can be used by DHCP protocol s/an ordering that can be/the ordering that must be/ or "is to be". I.e, this document is defining what is to be done. Saying "can be" makes it sound like an option. bytes. DHCP protocol agents MAY use the ordering described here to encode existing options if such options exceed 255 bytes in length. The main purpose of this specification, however, is to provide a specification that new DHCP option drafts can reference. I think the MAY above is wrong. The purpose of this spec is to define what the right thing to do is here. Most RFCs define new behavior that existing deployments don't support. That is not a problem. I am also confused that the purpose is only for new options. This should clarify/fix ambiguities in previous specs, where it is not sufficently well defined what clients and servers do. Presumably, there are already resultant interoperability problems due to these ambiguities. > allowing the client to rendesvous with DHCP servers, and so spelling > In this document, the key words "MAY", "MUST, "MUST NOT", > "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be > interpreted as described in [3]. I think "optional" and "recommended" should be capitalized above; the lower case versions are not defined in 2119. > space in another output buffer for the rest. DHCP protocol > agents encoding an option in this case MAY use the algorithm > specified here. MAY->MUST > The rationale for making this optional is that existing > implementations have not been subject to a requirement to encode > or decode options in this way, and it is not our intention to > potentially cause existing implementations to be in violation of > this specification. I understand the desire, but I strongly disagree with it. What is the harm in making existing implementations non-conforming to this spec? There are lots of specs that implementations don't conform to. The goal here is to get everyone to do the Right Thing. > This behaviour only applies in cases where this specification is > applicable, as previously defined in the Applicability section. A bit repetitive. The entire document is optional, so anything in it applies only if an implementation is attempting to conform to it. > DHCP options can be stored in the DHCP packet in three seperate > portions of the packet. These are the optional parameters > field, the sname field, and the file field, as described in [1]. > This complicates the description of the option splitting > mechanism because there are three seperate buffers into which > split options may be stored. Here you are using slightly different terminology than in the definition of "option overload" at the beginning of the document. It would be better to be consistent. Indeed, can't this text just be merged with the earlier definition? I think this would clarify the document, as the applicability section talks about the three buffers without having provided all the context (i.e, the description that comes here). > Options MUST NOT be stored in the aggregate option buffer in such > in such a way that they cross either boundary between the three > fields in the aggregate buffer. Is this MUST NOT new language, or is this already a requirement from the base DHCP spec? (I would assume the latter.) If this requirement comes from elsewhere, it would be better to say something like: Options must not be stored in the aggregate option buffer ... as described in [RFC XXX]. also, s/stored/placed/ ?? > Encoding agents MAY split options as described in this > specification. Encoding agents supporting options that require > this MUST split options as described here, if it is necessary to > do so in order to encode the entire contents of the option. Seems redundant, and MAY doesn't seem what is needed. > Options MAY be split on any octet boundary. No split portion of Use of MAY here seems wrong. The definition of MAY in 2119 says: 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) What other choice is there except to split on an octet boundary? Better to say something like "Options can only be split on ..." > The split portions of the option MUST be stored in the aggregate > option buffer in sequential order - the first split portion MUST > be stored first in the aggregate option buffer, then the second > portion, and so on. The above language seems to suggest that all of the BOOTP buffers must be used. Is an implementation required to do this? I.e., is this defining a new requirement? Can't an implementation leave (say) sname empty but use other fields? (I really don't know, so this is really a question.) > When a decoding agent is scanning an incoming DHCP packet's > option buffer and finds two or more options with the same option > code, it MAY consider them to be a split option as described > here. Decoding agents that support options that require the MAY->MUST Question: is there any existing DHCP option that can appear more than once, where the concatenating the two options results in different behavior than having the option appear twice? (I would assume not.) > behaviour. The decoding agent MUST ensure that when the > option's value is used, any alignment issues that are particular > to the machine architecture on which the decoding agent is > running are accounted for - there is no requirement that the > encoding agent align the options in any particular way. This above MUST language seems to be about an implementation issue that wouldn't normally be a protocol issue. This doesn't seem like it should be a *required* part of the spec. It would be fine to give advice to implementors to not do something dumb here. > Consider an option, option 224, with a value of "isc.org.". > Normally, this would be encoded as a single option, as follows: I think it would be better to use a real example (224 is out of private space). Or, add text saying that the contents of the option doesn't matter, since the operation of splitting an concatenating options takes place assuming the contents of the option value are opaque. > Security Considerations > > DHCP currently provides no authentication or security mechanisms. > Potential exposures to attack are discussed in section 7 of the DHCP > protocol specification [1]. The Classless Static Routes option can > be used to misdirect network traffic by providing incorrect IP > addresses for routers. The purpose of a security considerations section is to discuss issues related to the topic of the document itself. I think it would be more appropriate to say, that this document raises no new issues that are not already present in DHCP (assuming this is actually correct!) and then site the relevant docs as you do. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 13:27:12 2001 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 NAA24197; Wed, 26 Sep 2001 13:27:12 -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 NAA08581; Wed, 26 Sep 2001 13:24:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08551 for ; Wed, 26 Sep 2001 13:24:23 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24096 for ; Wed, 26 Sep 2001 13:24:19 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA21080 for ; Wed, 26 Sep 2001 13:23:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20010926131053.00ba9d80@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Sep 2001 13:23:14 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] draft-ietf-dhc-concat-01.txt In-Reply-To: <200109261429.KAA15509@rotala.raleigh.ibm.com> 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: X-BeenThere: dhcwg@ietf.org Thomas - I want to make sure I understand your point and to clarify the status of existing implementations. Once draft-ietf-dhc-concat-01.txt is accepted as a standard, it will be considered as a distinct part of the DHCP standard. Existing implementations will still be in compliance with the DHCP specification in RFC2131 and RFC2132. However, existing implementations might not be in compliance with the new option concatenation standard. With this interpretation, the wording you suggest for the option concatenation draft would not cause existing implementations to now become out of compliance with the DHCP standard. Do I have this right? - Ralph At 10:29 AM 9/26/2001 -0400, Thomas Narten wrote: >Major issue: > >The document goes to great lengths to NOT make existing >clients/servers out of spec with this ID. This seems misguided. Most >RFCs define new behavior. That existing implementations don't follow >the RFC is not a problem. Indeed, the goal is to make sure all future >implementations (or updates to existing implementations) adhere to the >new spec. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 13:51:32 2001 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 NAA24928; Wed, 26 Sep 2001 13:51:31 -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 NAA09294; Wed, 26 Sep 2001 13:48: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 NAA09268 for ; Wed, 26 Sep 2001 13:48:50 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24857 for ; Wed, 26 Sep 2001 13:48:41 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA24577; Wed, 26 Sep 2001 13:47:31 -0400 (EDT) Message-Id: <4.3.2.7.2.20010926134104.03d8b110@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Sep 2001 13:45:25 -0400 To: Bernard Aboba From: Ralph Droms Subject: Re: [dhcwg] Incorporation of WG last call comments in draft-aboba-dhc-domsearch-06.txt Cc: Thomas Narten , dhcwg@ietf.org In-Reply-To: References: <200109261102.f8QB27P04976@hygro.adsl.duke.edu> 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: X-BeenThere: dhcwg@ietf.org My comments are in line... - Ralph At 07:00 AM 9/26/2001 -0700, Bernard Aboba wrote: > > Main item is that it has a normative reference to > > > > > [7] Lemon, T., "Encoding Long DHCP Options", Internet draft (work in > > > progress), draft-ietf-dhc-concat-01.txt, July 2001. > > > > so these two document should go together. > >Not sure the reference is normative. This option can use the long option >encoding if available, but doesn't require it. Agreed; in fact, I think you could eliminate references to the long option encoding draft w/o harming your spec... > > > > Some minor wording nits (these can be dealt with later): > > > > > the domain search list. This document defines a new DHCP option which > > > is passed from the DHCP Server to the DHCP Client to specify the domain > > > search list when resolving hostnames. > > > > Is the option allowed to be included in client messages? I would > > assume so. Indeed, isn't it the case that clients can include any > > option if to signal a desire to the server to get such an option > > returned? If so, I guess this isn't really an issue. > >Yes, that's my understanding. Perhaps it would be easiest to change the sentence to: This document defines a new DHCP option that specifies the domain search list to be used by a DHCP client when resolving hostnames. > > > > > In this scheme, an entire domain name or a list of labels at the end of > > > a domain name is replaced with a pointer to a prior occurrence of the > > > > s/is replaced/can be replaced/ > > > > > same name. Despite its complexity, this technique is valuable since the > > > > Thomas > > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 14:47:58 2001 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 OAA26034; Wed, 26 Sep 2001 14:47:54 -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 OAA11199; Wed, 26 Sep 2001 14:44:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11176 for ; Wed, 26 Sep 2001 14:44:20 -0400 (EDT) Received: from extmail02m.raleigh.ibm.com (extmail02.raleigh.ibm.com [204.146.167.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25987 for ; Wed, 26 Sep 2001 14:44:18 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [192.168.1.107]) by extmail02m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id OAA29256; Wed, 26 Sep 2001 14:41:28 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id OAA34470; Wed, 26 Sep 2001 14:42:53 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA16579; Wed, 26 Sep 2001 14:40:55 -0400 Message-Id: <200109261840.OAA16579@rotala.raleigh.ibm.com> To: Ralph Droms cc: Bernard Aboba , dhcwg@ietf.org Subject: Re: [dhcwg] Incorporation of WG last call comments in draft-aboba-dhc-domsearch-06.txt In-Reply-To: Message of "Wed, 26 Sep 2001 13:45:25 EDT." <4.3.2.7.2.20010926134104.03d8b110@funnel.cisco.com> Date: Wed, 26 Sep 2001 14:40:54 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Ralph Droms writes: > At 07:00 AM 9/26/2001 -0700, Bernard Aboba wrote: > > > Main item is that it has a normative reference to > > > > > > > [7] Lemon, T., "Encoding Long DHCP Options", Internet draft (work in > > > > progress), draft-ietf-dhc-concat-01.txt, July 2001. > > > > > > so these two document should go together. > > > >Not sure the reference is normative. This option can use the long option > >encoding if available, but doesn't require it. > Agreed; in fact, I think you could eliminate references to > the long option encoding draft w/o harming your spec... This make sense to me. I will note, however, that current wording in the concat draft could be interpret to suggest that it's intended for future options and maybe less so for existing options. If the intent is in fact that it the concat draft should apply to *all* DHCP options, then taking out the reference would be fine. If that is the intent, I'll go ahead and start the IETF last call on domsearch. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 15:04:14 2001 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 PAA26494; Wed, 26 Sep 2001 15:04:14 -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 PAA12060; Wed, 26 Sep 2001 15:01:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12034 for ; Wed, 26 Sep 2001 15:01:54 -0400 (EDT) Received: from extmail01m.raleigh.ibm.com (extmail01.raleigh.ibm.com [204.146.167.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26448 for ; Wed, 26 Sep 2001 15:01:51 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [192.168.1.109]) by extmail01m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id PAA24176; Wed, 26 Sep 2001 15:01:16 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id PAA29142; Wed, 26 Sep 2001 15:01:15 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA16644; Wed, 26 Sep 2001 14:59:16 -0400 Message-Id: <200109261859.OAA16644@rotala.raleigh.ibm.com> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-concat-01.txt In-Reply-To: Message of "Wed, 26 Sep 2001 13:23:14 EDT." <4.3.2.7.2.20010926131053.00ba9d80@funnel.cisco.com> Date: Wed, 26 Sep 2001 14:59:16 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Ralph Droms writes: > Thomas - I want to make sure I understand your point > and to clarify the status of existing implementations. > Once draft-ietf-dhc-concat-01.txt is accepted as a standard, > it will be considered as a distinct part of the DHCP > standard. Existing implementations will still be in > compliance with the DHCP specification in RFC2131 and RFC2132. > However, existing implementations might not be in compliance > with the new option concatenation standard. Right. Note that this is not unlike when an existing Proposed Standard gets reissued as a new RFC, still at Proposed Standard. The old one doesn't just vanish, even though one hopes/expects that everyone will update implementations to be compliant with the newer one. > With this interpretation, the wording you suggest for the > option concatenation draft would not cause existing > implementations to now become out of compliance with > the DHCP standard. > Do I have this right? Yep. At some future time (i.e, when 2131 and 2132 get reissued), it might well make sense to just merge the concat text into that one. But even then, we'd have the situation that there is the old RFC and the new one and existing implementations may not adhere to the new one 100%, at least at first. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 15:05:40 2001 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 PAA26573; Wed, 26 Sep 2001 15:05:40 -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 PAA12113; Wed, 26 Sep 2001 15:03:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12087 for ; Wed, 26 Sep 2001 15:03:17 -0400 (EDT) Received: from internaut.com ([64.38.134.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26456 for ; Wed, 26 Sep 2001 15:03:12 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id LAA26163; Wed, 26 Sep 2001 11:55:03 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 26 Sep 2001 11:55:03 -0700 (PDT) From: Bernard Aboba To: Thomas Narten cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] Incorporation of WG last call comments in draft-aboba-dhc-domsearch-06.txt In-Reply-To: <200109261840.OAA16579@rotala.raleigh.ibm.com> Message-ID: 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: X-BeenThere: dhcwg@ietf.org > > >Not sure the reference is normative. This option can use the long option > > >encoding if available, but doesn't require it. > > > Agreed; in fact, I think you could eliminate references to > > the long option encoding draft w/o harming your spec... > > This make sense to me. I will note, however, that current wording in > the concat draft could be interpret to suggest that it's intended for > future options and maybe less so for existing options. If the intent > is in fact that it the concat draft should apply to *all* DHCP > options, then taking out the reference would be fine. > > If that is the intent, I'll go ahead and start the IETF last call on > domsearch. I had thought that concat would apply to all DHCP options that could potentially run over the current limit. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 15:35:22 2001 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 PAA27134; Wed, 26 Sep 2001 15:35:21 -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 PAA12840; Wed, 26 Sep 2001 15:27: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 PAA12816 for ; Wed, 26 Sep 2001 15:27:49 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27007 for ; Wed, 26 Sep 2001 15:27:44 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA10488; Wed, 26 Sep 2001 15:26:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20010926152316.03d8a8d8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Sep 2001 15:26:15 -0400 To: Bernard Aboba From: Ralph Droms Subject: Re: [dhcwg] Incorporation of WG last call comments in draft-aboba-dhc-domsearch-06.txt Cc: Thomas Narten , dhcwg@ietf.org In-Reply-To: References: <200109261840.OAA16579@rotala.raleigh.ibm.com> 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: X-BeenThere: dhcwg@ietf.org RFC2131 allows for options that can carry data values longer than 255 bytes, so my understanding, too, is that the option concatenation standard would apply to all DHCP options. - Ralph At 11:55 AM 9/26/2001 -0700, Bernard Aboba wrote: > > > >Not sure the reference is normative. This option can use the long option > > > >encoding if available, but doesn't require it. > > > > > Agreed; in fact, I think you could eliminate references to > > > the long option encoding draft w/o harming your spec... > > > > This make sense to me. I will note, however, that current wording in > > the concat draft could be interpret to suggest that it's intended for > > future options and maybe less so for existing options. If the intent > > is in fact that it the concat draft should apply to *all* DHCP > > options, then taking out the reference would be fine. > > > > If that is the intent, I'll go ahead and start the IETF last call on > > domsearch. > >I had thought that concat would apply to all DHCP options that could >potentially run over the current limit. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 16:24:12 2001 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 QAA27939; Wed, 26 Sep 2001 16:24:12 -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 QAA14930; Wed, 26 Sep 2001 16:17:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14903 for ; Wed, 26 Sep 2001 16:17:44 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27867 for ; Wed, 26 Sep 2001 16:17:40 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f8QKHf712976 for ; Wed, 26 Sep 2001 15:17:41 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8QKHf727476 for ; Wed, 26 Sep 2001 15:17:41 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Sep 26 15:17:40 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 15:17:40 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3697@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , Bernard Aboba Cc: Thomas Narten , dhcwg@ietf.org Subject: RE: [dhcwg] Incorporation of WG last call comments in draft-aboba -dhc-domsearch-06.txt Date: Wed, 26 Sep 2001 15:17:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C146C8.46E1C810" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C146C8.46E1C810 Content-Type: text/plain; charset="iso-8859-1" Please do note that there is no way a client (or server) can know if the other entity supports this concat behavior. I think what Bernard was trying to assure is that anyone that implements the domsearch option must also implement the concat behavior. Since this is perhaps an option that could result in an option longre than 255 bytes, it makes sense to do this. One thing that does concern me about the concat option (really belongs to the other thread on that matter) is that there is no way a client (or server) can know if the other entity support the concat behavior. And, suppose a server sends an domsearch option which is concat, what if the client doesn't do the concat and uses the last (or first) instance. The domain search list that client uses would be very broken. Another issue for concat option is what happens if an option is split because it crosses a buffer boundry - in this case, it isn't even long options that are affected. And, again, if a client doesn't concat that option ... -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, September 26, 2001 3:26 PM To: Bernard Aboba Cc: Thomas Narten; dhcwg@ietf.org Subject: Re: [dhcwg] Incorporation of WG last call comments in draft-aboba-dhc-domsearch-06.txt RFC2131 allows for options that can carry data values longer than 255 bytes, so my understanding, too, is that the option concatenation standard would apply to all DHCP options. - Ralph At 11:55 AM 9/26/2001 -0700, Bernard Aboba wrote: > > > >Not sure the reference is normative. This option can use the long option > > > >encoding if available, but doesn't require it. > > > > > Agreed; in fact, I think you could eliminate references to > > > the long option encoding draft w/o harming your spec... > > > > This make sense to me. I will note, however, that current wording in > > the concat draft could be interpret to suggest that it's intended for > > future options and maybe less so for existing options. If the intent > > is in fact that it the concat draft should apply to *all* DHCP > > options, then taking out the reference would be fine. > > > > If that is the intent, I'll go ahead and start the IETF last call on > > domsearch. > >I had thought that concat would apply to all DHCP options that could >potentially run over the current limit. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C146C8.46E1C810 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Incorporation of WG last call comments in = draft-aboba-dhc-domsearch-06.txt

Please do note that there is no way a client (or = server) can know if the other entity supports this concat = behavior.

I think what Bernard was trying to assure is that = anyone that implements the domsearch option must also implement the = concat behavior.

Since this is perhaps an option that could result in = an option longre than 255 bytes, it makes sense to do this.

One thing that does concern me about the concat = option (really belongs to the other thread on that matter) is that = there is no way a client (or server) can know if the other entity = support the concat behavior. And, suppose a server sends an domsearch = option which is concat, what if the client doesn't do the concat and = uses the last (or first) instance. The domain search list that client = uses would be very broken.

Another issue for concat option is what happens if an = option is split because it crosses a buffer boundry - in this case, it = isn't even long options that are affected. And, again, if a client = doesn't concat that option ...

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, September 26, 2001 3:26 PM
To: Bernard Aboba
Cc: Thomas Narten; dhcwg@ietf.org
Subject: Re: [dhcwg] Incorporation of WG last call = comments in
draft-aboba-dhc-domsearch-06.txt


RFC2131 allows for options that can carry
data values longer than 255 bytes, so my = understanding,
too, is that the option concatenation standard = would
apply to all DHCP options.

- Ralph

At 11:55 AM 9/26/2001 -0700, Bernard Aboba = wrote:
> > > >Not sure the reference is = normative. This option can use the long option
> > > >encoding if available, but = doesn't require it.
> >
> > > Agreed; in fact, I think you could = eliminate references to
> > > the long option encoding draft w/o = harming your spec...
> >
> > This make sense to me. I will note, = however, that current wording in
> > the concat draft could be interpret to = suggest that it's intended for
> > future options and maybe less so for = existing options. If the intent
> > is in fact that it the concat draft should = apply to *all* DHCP
> > options, then taking out the reference = would be fine.
> >
> > If that is the intent, I'll go ahead and = start the IETF last call on
> > domsearch.
>
>I had thought that concat would apply to all = DHCP options that could
>potentially run over the current limit.


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

------_=_NextPart_001_01C146C8.46E1C810-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 16:57:25 2001 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 QAA28565; Wed, 26 Sep 2001 16:57:25 -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 QAA15796; Wed, 26 Sep 2001 16:51:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15767 for ; Wed, 26 Sep 2001 16:51:27 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28481 for ; Wed, 26 Sep 2001 16:51:22 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA22504 for ; Wed, 26 Sep 2001 16:50:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20010926162221.03d8a8d8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Sep 2001 16:43:24 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Results of recent WG last calls Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org After the IETF meeting in London, several drafts were submitted for WG last call. Here are the results of those last calls and the disposition of the drafts: DHCP Domain Search Option Changes suggested in WG response; -06 rev published Submitted for IETF last call Subnet Selection sub-option for the Relay Agent Information Option No comments during WG last call Ready for submission for IETF last call Addition of Device Class to Agent Options No comments during WG last call Ready for submission for IETF last call (draft expired and will be resubmitted) DHCP Failover Protocol No comments during WG last call Ready for submission for IETF last call Encoding Long DHCP Options Changes suggested in WG response, revision to be submitted The Classless Static Route Option for DHCP Changes suggested in WG response, revision to be submitted The DHCP Client FQDN Option Resolution of DNS Name Conflicts Among DHCP Clients Changes suggested in WG response, revision to be submitted _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 17:31:22 2001 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 RAA29257; Wed, 26 Sep 2001 17:31:22 -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 RAA16629; Wed, 26 Sep 2001 17:28:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16602 for ; Wed, 26 Sep 2001 17:28:15 -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 RAA29193 for ; Wed, 26 Sep 2001 17:27:58 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-229.ip.theriver.com [205.140.116.229]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f8QJaWv24730; Wed, 26 Sep 2001 12:36:36 -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 f8QJchZ07668; Wed, 26 Sep 2001 12:38:43 -0700 (MST) Message-Id: <200109261938.f8QJchZ07668@grosse.bisbee.fugue.com> To: Thomas Narten cc: Bernard Aboba , dhcwg@ietf.org Subject: Re: [dhcwg] Incorporation of WG last call comments in draft-aboba-dhc-domsearch-06.txt In-Reply-To: Message from Thomas Narten of "Wed, 26 Sep 2001 07:02:07 -0400." <200109261102.f8QB27P04976@hygro.adsl.duke.edu> Date: Wed, 26 Sep 2001 12:38:43 -0700 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > > [7] Lemon, T., "Encoding Long DHCP Options", Internet draft (work in > > progress), draft-ietf-dhc-concat-01.txt, July 2001. We're in last call on the concat option as well, and I have a new version with some changes suggested by Stuart Cheshire. I think it's ready to go. So I'll publish it now. > Is the option allowed to be included in client messages? I would > assume so. Indeed, isn't it the case that clients can include any > option if to signal a desire to the server to get such an option > returned? If so, I guess this isn't really an issue. It doesn't make sense to include this in a client message, but the draft isn't saying a server should drop a message that contains this option, so I think this is a non-issue. > s/is replaced/can be replaced/ The wording only applies if you are doing compression, so the definite form of the verb is correct, and the indefinite form would be less correct, IMHO. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 26 21:11:22 2001 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 VAA01898; Wed, 26 Sep 2001 21:11:22 -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 VAA21400; Wed, 26 Sep 2001 21:08:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21378 for ; Wed, 26 Sep 2001 21:08:39 -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 VAA01833 for ; Wed, 26 Sep 2001 21:08:33 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-229.ip.theriver.com [205.140.116.229]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f8R18Tv25163; Wed, 26 Sep 2001 18:08:29 -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 f8R11fZ08240; Wed, 26 Sep 2001 18:01:41 -0700 (MST) Message-Id: <200109270101.f8R11fZ08240@grosse.bisbee.fugue.com> To: "Bernie Volz (EUD)" cc: "'Ralph Droms'" , Bernard Aboba , Thomas Narten , dhcwg@ietf.org Subject: Re: [dhcwg] Incorporation of WG last call comments in draft-aboba -dhc-domsearch-06.txt In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 26 Sep 2001 15:17:33 EST." <66F66129A77AD411B76200508B65AC697B3697@eambunt705.ena-east.ericsson.se> Date: Wed, 26 Sep 2001 18:01:41 -0700 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I have to agree with Bernie here - the point of referencing the concat option is to make *sure* that a client that does domsearch (or csr) also supports concat. A client that implements domsearch or csr but not concat then becomes non-conforming. If domsearch or csr doesn't *require* concat, then this is not the case, and the server doesn't know whether or not it can do concat. So domsearch and csr *must* require concat. And this is why concat is worded the way it is - if it were required across the board, it would be useless, because there would be no way of telling DHCP agents that support it from DHCP agents that don't. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 27 11:43:55 2001 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 LAA04236; Thu, 27 Sep 2001 11:43:51 -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 LAA24656; Thu, 27 Sep 2001 11:41:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24625 for ; Thu, 27 Sep 2001 11:41:45 -0400 (EDT) Received: from hotmail.com (f68.law4.hotmail.com [216.33.149.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04191 for ; Thu, 27 Sep 2001 11:41:44 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 27 Sep 2001 08:41:14 -0700 Received: from 12.153.34.50 by lw4fd.law4.hotmail.msn.com with HTTP; Thu, 27 Sep 2001 15:41:14 GMT X-Originating-IP: [12.153.34.50] From: "Huma Hakim" To: dhcwg@ietf.org Date: Thu, 27 Sep 2001 15:41:14 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Sep 2001 15:41:14.0218 (UTC) FILETIME=[D6FE4CA0:01C1476A] Subject: [dhcwg] Design Issue Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hello I have a set-up in which one or more host machines may be connected to my dhcp server through a box X( This box X routes along with serving other functions too like sending packets from the host machines to my central station where the dhcp server is situated). Box X as well as these host machines may (optional) also connected to another LAN through another router A which cannot be configured by me as it does not belong to me. ----------------- |---------| |-Host m/c |Central Station |---------| Box X |------| |DHCP Server | | | |-------RouterA----LAN ----------------- |---------| | (optional) (opt) | |-Host m/c | | | | |----------|---------| |-Host m/c | | Box Y |------| | | | |-------Router B----LAN | |---------| | (optional) (opt) | |-Host m/c | | | |--------------- | | | |--------------- | | My job is to assign an IP address and subnet mask at the very least to my box A as well as to all the host machines that may be connected to my box A through a DHCP server that my box A talks to at the central repository. All the host machines connected to my box A communicate to my central repository to obtain data/information via my box A. I could have a number of such boxes along with their respective host machines that communicate simultaneously to my central station.All these boxes have to have different subnets coz essentially they are all routers, and no two routers can belong to the same subnet. For these boxes/host machines groups to talk to each other , packets have to be routed by my central repository.The message is first sent to the central side and then a router there will route the packet and send it back to the appropriate box. Hence if more than one box has the same subnet, the router on the central side will not know which interface to send the packet to in order to reach a particular box Cable modems and DSL might have a similar problem but im sure they dont care if their subnets overlap coz it doesnt affect their functionality The different scenarious are: 1. stub network 2.Networks with public and well as private addressing(may have some implementation like NAT) or i might have to use something like that 3. Networks which might have public and private addressing as well as be multihomed. The main criteria is that the DHCP server should be on our the central respoitory side. i.e. it should provide dhcp addressing Any of the boxes( could be called routers as in routing traffic to the central station) or host machines connected to our box should be able to ask for an address if it needs one. If the ip address we assign to either a box or a host machine is on a different subnet from the LAN to which they are attached to, an address entry (subnet entry) in the router table (maybe use RIP ??) may have to be done The problem is what subnet do i assign to this box or host machine i.e. on what basis do i have entries in my dhcp server? coz they cannot be based on hardware addresses as a host machine can have just abt any h/w address which i have no control over.. Aim is to give ip's and subnet masks to ppl who ask my server but how do i relate all of them My dhcp client software which will reside on my box needs to act like a dhcp client when it is asking for a subnet and ip address for itself and as a relay agent when it is asking for a subnet and ip address for the host machines attached to it. So obviously till my box does not come up and get initialized it cannot act like a relay agent(as it has no idea what its configuration is till it contacts my dhcp server) I hope i was able to put my problem across.. my aim is to find some architecure to make this design possible. I would be very grateful if someone could help me out or point me to some relevant material One possible solution was to send the MAc address of my box as the agent circuit id sub option in the dhcp agent information option and let the MAC addresses of the host machines act as the agent remote id suboption but I am sure a better solution exist _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 27 11:49:32 2001 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 LAA04365; Thu, 27 Sep 2001 11:49:31 -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 LAA24778; Thu, 27 Sep 2001 11:48:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24753 for ; Thu, 27 Sep 2001 11:48:45 -0400 (EDT) Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04349 for ; Thu, 27 Sep 2001 11:48:43 -0400 (EDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id f8RFkGo02071 for ; Thu, 27 Sep 2001 11:46:16 -0400 Message-Id: <200109271546.f8RFkGo02071@hygro.adsl.duke.edu> To: dhcwg@ietf.org Date: Thu, 27 Sep 2001 11:46:15 -0400 From: Thomas Narten Subject: [dhcwg] draft-ietf-dhc-agent-subnet-selection-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Overall, this document is probably close enough to being ready for IETF Last Call. It would be good to add an IANA considerations section though, since IANA will be looking for such a section during the IETF last call. Any chance of getting this document revved quickly (i.e, in the next couple of days)? If so, I'd like to delay the last call until then. If this can't be done quickly, I'll go ahead and start the last call anyay. Let me know either way. Thomas Comments: > The subnet-selection sub-option MAY be used by any DHCP relay agent MAY not really needed. Implementation of the document itself is optional, by definition. Servers supporting this sub-option MUST return an identical copy of the sub-option in the relay-agent-info option to any relay-agent that sends it. Relay agents using this sub-option MUST discard DHCPOFFER or DHCPACK packets that do not contain this option in their associ- ated relay-agent-info options. This is redundent text from RFC 3046. Either drop (isn't RFC 3046 clear enough on this point?), or put in a reference to RFC 3046, making it clear that the above requirement is a generic requirement of all relay agent options, and not one specific to this sub-option. > 4. Security Append "Considerations" to the heading. :-) > DHCP currently provides no authentication or security mechanisms. > Potential exposures to attack are discussed is section 7 of the pro- > tocol specification [RFC 2131]. The subnet selection option allows a > relay agent to specify the subnet on which to allocate an address for > a DHCP client. This would allow a malicious DHCP client to perform a > more complete address-pool exhaustion attack since the client would > no longer be restricted to attacking address-pools on just its local > subnet. Under the current DHCP security model there are no methods > available to circumvent this type of attack. Security considerations could be a bit better. I.e., say something about *this* sub-option. But the text talks about the "client" (as in the generic subnet option RFC 3011 case?) rather than the relay agent. This could be better clarified. Also, isn't the relay agent more trusted in many configurations than a client? If so, the issues would seem to be different. Document needs an IANA considerations section to provide IANA with a heads up that they have an assignment to make. E.g.,.,: IANA has assigned a value of TBD from the DHCP Relay Agent Sub-options space [RFC 3046] for the subnet selection sub-option defined in Section 3. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 27 12:13:24 2001 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 MAA05261; Thu, 27 Sep 2001 12:13:24 -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 MAA26096; Thu, 27 Sep 2001 12:10:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26067 for ; Thu, 27 Sep 2001 12:10:34 -0400 (EDT) Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05132 for ; Thu, 27 Sep 2001 12:10:32 -0400 (EDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id f8RG85D02372 for ; Thu, 27 Sep 2001 12:08:05 -0400 Message-Id: <200109271608.f8RG85D02372@hygro.adsl.duke.edu> To: dhcwg@ietf.org Date: Thu, 27 Sep 2001 12:08:05 -0400 From: Thomas Narten Subject: [dhcwg] draft-ietf-dhc-agentoptions-device-class-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Ralph Droms writes: > Addition of Device Class to Agent Options > > No comments during WG last call > Ready for submission for IETF last call > (draft expired and will be resubmitted) I managed to find a copy of -01; here are my comments on this one: needs IANA considerations section (see previous note on subnet ID) uses MAY language without definition. Maybe just downcase the words and use the english meaning instead? > SubOpt Len Device Class > +------+------+------+------+------+------+------+------+-- > | TBD | n | d1 | d2 | d3 | d4 | d5 | d6 | ... > +------+------+------+------+------+------+------+------+-- It would be good in the text under this picture to list the fields and what their values are. I.e., is "n" variable length or always the same? Also, is the specific meaning/definition/interpretation of the Device Class field defined in: > [3] "Data-Over-Cable Service Interface Specifications: Cable Modem > Radio Frequency Interface Specification SP-RFIv1.1-I06-001215", > DOCSIS, December 2000, http://www.cablemodem.com. (I assume so from the previous text). It would be good to state this explicitly, since the text does say that the server must be able to parse this field in order to figure out what parameters to return. And since we've been talking about this issue elsewhere, will this option always be less than 255 bytes? :-) Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 27 18:52:23 2001 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 SAA14792; Thu, 27 Sep 2001 18:52:18 -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 SAA06894; Thu, 27 Sep 2001 18:49:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06866 for ; Thu, 27 Sep 2001 18:49:06 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14741 for ; Thu, 27 Sep 2001 18:49:04 -0400 (EDT) Received: from rwoundy-w2k.cisco.com (ch2-dhcp140-105.cisco.com [161.44.140.105]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA07119; Thu, 27 Sep 2001 18:48:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20010927165436.019d3cf0@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Sep 2001 18:50:19 -0400 To: Thomas Narten , dhcwg@ietf.org From: Rich Woundy Subject: Re: [dhcwg] draft-ietf-dhc-agentoptions-device-class-01.txt Cc: doug@yas.com In-Reply-To: <200109271608.f8RG85D02372@hygro.adsl.duke.edu> 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: X-BeenThere: dhcwg@ietf.org Thomas, thanks for your comments, which really helped. My proposed resolutions are below. Any objections? If not, I will submit -03 by Monday. -- Rich At 12:08 PM 9/27/2001 -0400, Thomas Narten wrote: >Ralph Droms writes: > > > Addition of Device Class to Agent Options > > > > No comments during WG last call > > Ready for submission for IETF last call > > (draft expired and will be resubmitted) > >I managed to find a copy of -01; here are my comments on this one: I submitted -02 yesterday -- just to refresh the expired draft. Your comments will be reflected in version -03. >needs IANA considerations section (see previous note on subnet ID) I am adding the following section: 4. IANA Considerations IANA has assigned a value of TBD from the DHCP Relay Agent Sub- options space [RFC 3046] for the device class sub-option defined in section 2. >uses MAY language without definition. Maybe just downcase the words >and use the english meaning instead? I am removing one MAY statement from section 1 (in the spirit of other recent comments about obviousness): "This sub-option MAY be added by DHCP relay agents which terminate cable modems" to "This sub-option is added by DHCP relay agents which terminate cable modems". I am keeping one MAY from section 2 (since even DHCP servers that support this suboption may use other policy indicators): "DHCP servers MAY use the device class for IP and other parameter assignment policies for cable modems". I am adding one MUST to section 2 (since this is the whole point of the draft): "The relay agent passes the Device Class value unchanged to the DHCP server" to "The relay agent MUST pass the Device Class value unchanged to the DHCP server". I am adding the following paragraph to the Introduction: The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as described in RFC 2119 [4]. I am adding the reference to RFC 2119: [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. > > SubOpt Len Device Class > > +------+------+------+------+------+------+------+------+-- > > | TBD | n | d1 | d2 | d3 | d4 | d5 | d6 | ... > > +------+------+------+------+------+------+------+------+-- > >It would be good in the text under this picture to list the fields and >what their values are. I.e., is "n" variable length or always the >same? The DOCSIS specs say that their Device Class is a 32 bit value. Therefore I am changing 'n' to '4', and deleting the 'd5' and 'd6' bytes. Also see the comment below. >Also, is the specific meaning/definition/interpretation of the Device >Class field defined in: > > > [3] "Data-Over-Cable Service Interface Specifications: Cable Modem > > Radio Frequency Interface Specification SP-RFIv1.1-I06-001215", > > DOCSIS, December 2000, http://www.cablemodem.com. > >(I assume so from the previous text). It would be good to state this >explicitly, since the text does say that the server must be able to >parse this field in order to figure out what parameters to return. I am adding the following paragraph to section 2: DOCSIS defines the Device Class to be a 32-bit field where individual bits represent individual attributes of the CM. Bit #0 is the least significant bit of the field. Bits are set to 1 to select the attri- butes defined below. bit #0 - CPE Controlled Cable Modem (CCCM) bits #1-31 - Reserved and set to zero >And since we've been talking about this issue elsewhere, will this >option always be less than 255 bytes? :-) Yes -- thankfully. -- Rich >Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 27 19:53:04 2001 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 TAA15684; Thu, 27 Sep 2001 19:53:04 -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 TAA08507; Thu, 27 Sep 2001 19:52:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06350 for ; Thu, 27 Sep 2001 18:29:46 -0400 (EDT) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14552 for ; Thu, 27 Sep 2001 18:29:44 -0400 (EDT) Received: from fable5.Stanford.EDU (fable5.Stanford.EDU [171.64.15.198]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id f8RMTki19365 for ; Thu, 27 Sep 2001 18:29:46 -0400 (EDT) Received: (from tsranga@localhost) by fable5.Stanford.EDU (8.11.6/8.11.6) id f8RMTds11590; Thu, 27 Sep 2001 15:29:39 -0700 (PDT) Date: Thu, 27 Sep 2001 15:29:39 -0700 (PDT) From: Ranganath Sudarshan To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] question about basic broadcast Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi, I was trying to get the following scenario to work: On one machine on the LAN, you have a Java program listening on some port X for datagram packets coming in. On another box, which is running FreeBSD and which does NOT have an IP address configured (pre-DHCP configuration), I want to have code which broadcasts a message to 255.255.255.255, port X, and I want the other box running Java to pick up this datagram packet. int on = 1; char *msg = strdup("message"); sockfd = socket(AF_INET, SOCK_DGRAM, 0); setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on)); their_addr.sin_family = AF_INET; their_addr.sin_port = htons(MYPORT); their_addr.sin_addr.s_addr = inet_addr("255.255.255.255"); memset(&(their_addr.sin_zero), '\0', 8); numbytes = sendto(sockfd, msg, strlen(msg), MSG_DONTROUTE); numbytes is returned as -1 and the error: Network is Unreachable is returned. Does anyone know what the problem may be? My basic aim is to have the FreeBSD box without IP configured be able to communicate with my box running a Java Datagram listener. I would greatly appreciate any help on this matter. I realize that the problem is a subset of what DHCP enables one to do, but I wish to only have this simple functionality, and not all of the DHCP protocol. Thanks, RTS _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 28 07:05:06 2001 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 HAA08919; Fri, 28 Sep 2001 07:05:06 -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 HAA29874; Fri, 28 Sep 2001 07:03:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28628 for ; Fri, 28 Sep 2001 06:15:00 -0400 (EDT) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08464 for ; Fri, 28 Sep 2001 06:14:53 -0400 (EDT) From: Martin.Stiemerling@ccrle.nec.de Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id f8SAEvi11839 for ; Fri, 28 Sep 2001 06:14:58 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f8SAGIf98276; Fri, 28 Sep 2001 12:16:18 +0200 (CEST) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id C8B7BC113; Fri, 28 Sep 2001 12:14:55 +0200 (CEST) To: Ranganath Sudarshan Subject: Re: [dhcwg] question about basic broadcast Message-ID: <1001672095.3bb44d9fb9f7b@citadel.mobility.ccrle.nec.de> Date: Fri, 28 Sep 2001 12:14:55 +0200 (CEST) Cc: dhcp-v4@bucknell.edu References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.180 Content-Transfer-Encoding: 8bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Hi Ranganath, this list is for protocol developement issues, not for programing questions. Please try another available lists. By the way: The below C program will never compile, and if you use the right parameter in sendto() you'll have more success. Here is the definition of sendto: ssize_t sendto(int s, const void *msg, size_t len, int flags, const struct sockaddr *to, socklen_t tolen) See: http://www.freebsd.org/cgi/man.cgi? query=sendto&apropos=0&sektion=0&manpath=FreeBSD+4.3-RELEASE&format=html Zitiere Ranganath Sudarshan : > Hi, > I was trying to get the following scenario to work: > > On one machine on the LAN, you have a Java program listening on some > port > X for datagram packets coming in. > > On another box, which is running FreeBSD and which does NOT have an IP > address configured (pre-DHCP configuration), I want to have code which > broadcasts a message to 255.255.255.255, port X, and I want the other > box > running Java to pick up this datagram packet. > > int on = 1; > char *msg = strdup("message"); > sockfd = socket(AF_INET, SOCK_DGRAM, 0); > setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on)); > their_addr.sin_family = AF_INET; > their_addr.sin_port = htons(MYPORT); > their_addr.sin_addr.s_addr = inet_addr("255.255.255.255"); > memset(&(their_addr.sin_zero), '\0', 8); > numbytes = sendto(sockfd, msg, strlen(msg), MSG_DONTROUTE); > > numbytes is returned as -1 and the error: Network is Unreachable is > returned. > > Does anyone know what the problem may be? My basic aim is to have the > FreeBSD box without IP configured be able to communicate with my box > running a Java Datagram listener. I would greatly appreciate any help > on > this matter. I realize that the problem is a subset of what DHCP > enables > one to do, but I wish to only have this simple functionality, and not > all > of the DHCP protocol. > > Thanks, > RTS > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 28 07:10:52 2001 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 HAA09258; Fri, 28 Sep 2001 07:10:52 -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 HAA00004; Fri, 28 Sep 2001 07:09:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29977 for ; Fri, 28 Sep 2001 07:09:37 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09063; Fri, 28 Sep 2001 07:09:32 -0400 (EDT) Message-Id: <200109281109.HAA09063@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 28 Sep 2001 07:09:32 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agentoptions-device-class-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Addition of Device Class to Agent Options Author(s) : D. Jones, R. Woundy Filename : draft-ietf-dhc-agentoptions-device-class-02.txt Pages : 4 Date : 27-Sep-01 This document proposes a new sub-option to the DHCP Relay Information Agent Option. This new sub-option is for use with DOCSIS cable modems and describes a 'device class' to which the cable modem belongs. The cable modem signals its device class information to the Relay Agent using DOCSIS signalling, and the Relay Agent forwards the device class information to the DHCP Server which can then make a policy decision based on it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentoptions-device-class-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-agentoptions-device-class-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agentoptions-device-class-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010927141543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agentoptions-device-class-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agentoptions-device-class-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010927141543.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 28 11:42:53 2001 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 LAA17895; Fri, 28 Sep 2001 11:42:53 -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 LAA07250; Fri, 28 Sep 2001 11:41:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07223 for ; Fri, 28 Sep 2001 11:41:54 -0400 (EDT) Received: from extmail02m.raleigh.ibm.com (extmail02.raleigh.ibm.com [204.146.167.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17880 for ; Fri, 28 Sep 2001 11:41:48 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [192.168.1.108]) by extmail02m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id LAA21676 for ; Fri, 28 Sep 2001 11:39:55 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id LAA29052 for ; Fri, 28 Sep 2001 11:41:23 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id LAA24526 for ; Fri, 28 Sep 2001 11:39:00 -0400 Message-Id: <200109281539.LAA24526@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Fri, 28 Sep 2001 11:39:00 -0400 From: Thomas Narten Subject: [dhcwg] draft-ietf-dhc-csr-05.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Ralph Droms writes: > The Classless Static Route Option for DHCP > > Changes suggested in WG response, revision to be submitted Here are my comments on this document. NIT: The term "classed" (as in classed routing) isn't the common one, I think. "classful" is more common. > Subnet number Subnet mask Destination descriptor under destination descriptor, I think it would be potentially less confusing to NOT use the dotted terminology -- the first byte is not an address, for instance. I.e., just say something like: Subnet number Subnet mask Destination descriptor (octets in decimal) 0 0 0 10.0.0.0 255.0.0.0 8 10 10.229.0.128 255.255.255.128 25 10 229 0 128 > In some cases more than one IP subnet may be configured within a > given network broadcast domain. In such cases, a host whose IP > address is in one IP subnet in the broadcast domain could communicate > directly with a host whose IP address is in a different IP subnet in > the same broadcast domain. In cases where a client is being > assigned an IP address on an IP subnet in such a broadcast domain, Is the term "broadcast domain" the common terminology? I.e, in IPv6, one would say "multiple subnets on the same link". In IPv4, one might say "multiple subnets on the same physical network" or something else, I think. What terminology do other RFCs use (I'm pretty sure this is described somewhere)? It would be better to be consistent. > DHCP clients that do not support this option MUST ignore it if it > is received from a DHCP server. DHCP clients that support this Presumably they already ignore the option per existing RFCs? I.e, it seems odd to make it a requirement of *this* spec to specify behavior on an implementation that "does not support" the option... > DHCP clients that support this option and that send a DHCP > Parameter Request List option MUST request both this option and the > Router option [2] in the DHCP Parameter Request List. DHCP clients seems like MUST is too strong, and SHOULD would suffice. I.e, it might be that a client understands the option, but doesn't actually want the DHCP server to return such an option because it will ignore it or something. > request the Static Routes option. The Classless Static Routes > option code SHOULD appear in the parameter request list prior to > the Router option code. Why this SHOULD? I.e., if it is not a MUST, the server can't count on this being the case, so what is the benefit? > After deriving a subnet number and subnet mask from each > destination descriptor, the DHCP client SHOULD check the > combination of the network number and the subnet mask for validity. > If the network number contains nonzero bits beyond the subnet mask, > the client SHOULD discard that route. For example, the client > should not install a route with a destination of 129.210.377.4 and > a subnet mask of 255.255.255.128. I again am uncomfortable with SHOULDs here. I.e, they should be MUSTs or don't bother. The reasoning is that I assume the reason for specifying the above is to get consistent and predicatable behavior. I.e, if a server inserts an option with extra bits, either all clients should process the route, or all should ignore it. Having some clients do it one way, and others another does not promote interoperability. My personal preference would be to allow extra the bits. It's not that uncommon to provide a host address and a netmask to indicate a subnet number. I.e., it's work to figure out which bits should be chopped off and to actually set them to zero. But overall, the way clients process this case should be consistent across all implementations. > Because a full routing table can be quite large, the standard 576 > octet maximum size for a DHCP message may be too short to contain > some legitimate Classless Static Route options. Because of this, > clients implementing the Classless Static Route option SHOULD send > a Maximum DHCP Message Size [2] option if the DHCP client's TCP/IP > stack is capable of reassembling fragmented IP datagrams. In this > case, the client SHOULD set the value of this option to the MTU of > the interface that the client is configuring. If the client > supports UDP fragmentation, it MAY set the value of this option to > the size of the largest UDP packet it is prepared to accept. This text could use a bit of tweaking. Note that whether an implementation supports reassembly isn't relevant. The key issue is what is the largest IP packet that a receiving host is guaranteed to be able to accept, whether fragemented or not. One would expect it to be at least as big as the MTU of the interface, but it could be larger. The text should say something more like: client SHOULD set the value of this option to the value of the maximum length DHCP message it is willing to accept. Actually, the above text is rather ambiguous. I.e., does this value include the DHCP headers (yes, I'd guess). Does it include the IP/UDP header (I don't know). The above text comes from 2132, which I'd argue is unclear. I kind of doubt that this document is the one that should clarify this language, but if there is agreement on what the right thing to do is here, perhaps include it here? or writeup a 1 paragraph ID that specifies the right behavior? > DHCP servers sending this option MUST use the technique described > in [10] for sending options larger than 255 bytes when storing this > option in outgoing DHCP packets. DHCP clients supporting this > option MUST support the technique described in [10] when reading > this option from incoming DHCP packets. As written, this document too has a normative reference to the concat ID. > DHCP Server Considerations > > When a DHCP client requests both the Router option and the > Classless Static Routes option, and the DHCP server is configured > with both a Classless Static Routes option and a Router option > that applies to the client, the DHCP server MAY exclude the Router > option from its response. Seems like MAY should be SHOULD. There is no reason to include it in this case. Right? Needs an IANA considerations section so that IANA knows to assign a code point. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 28 11:51:03 2001 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 LAA18074; Fri, 28 Sep 2001 11:51: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 LAA07524; Fri, 28 Sep 2001 11:50:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07499 for ; Fri, 28 Sep 2001 11:50:17 -0400 (EDT) Received: from extmail02m.raleigh.ibm.com (extmail02.raleigh.ibm.com [204.146.167.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18054 for ; Fri, 28 Sep 2001 11:50:11 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [192.168.1.108]) by extmail02m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id LAA36918; Fri, 28 Sep 2001 11:48:10 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id LAA29114; Fri, 28 Sep 2001 11:49:38 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id LAA24602; Fri, 28 Sep 2001 11:47:14 -0400 Message-Id: <200109281547.LAA24602@rotala.raleigh.ibm.com> To: Rich Woundy cc: dhcwg@ietf.org, doug@yas.com Subject: Re: [dhcwg] draft-ietf-dhc-agentoptions-device-class-01.txt In-Reply-To: Message of "Thu, 27 Sep 2001 18:50:19 EDT." <4.3.2.7.2.20010927165436.019d3cf0@funnel.cisco.com> Date: Fri, 28 Sep 2001 11:47:14 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi Rich. All your proposed changes look good to me. Thanks. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 28 14:17:35 2001 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 OAA21629; Fri, 28 Sep 2001 14:17:35 -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 OAA15088; Fri, 28 Sep 2001 14:14:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15069 for ; Fri, 28 Sep 2001 14:14:47 -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 OAA21565 for ; Fri, 28 Sep 2001 14:14:40 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-229.ip.theriver.com [205.140.116.229]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f8SIEbv29088; Fri, 28 Sep 2001 11:14:38 -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 f8SIAgl00427; Fri, 28 Sep 2001 11:10:42 -0700 (MST) Message-Id: <200109281810.f8SIAgl00427@grosse.bisbee.fugue.com> To: Thomas Narten cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-csr-05.txt In-Reply-To: Message from Thomas Narten of "Fri, 28 Sep 2001 11:39:00 -0400." <200109281539.LAA24526@rotala.raleigh.ibm.com> Date: Fri, 28 Sep 2001 11:10:42 -0700 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > NIT: The term "classed" (as in classed routing) isn't the common one, > I think. "classful" is more common. Classful is not a common english word, so I'm reluctant to use it in an RFC, even if it's common in the vernacular of network administrators. I could change it to "class-based", but I think "classed" conveys the meaning, plus it's a real word, so my inclination is to keep it. I can't see how this can create confusion - the relevant RFCs are referenced, and a brief definition of the term is given. > Is the term "broadcast domain" the common terminology? I.e, in IPv6, > one would say "multiple subnets on the same link". In IPv4, one might > say "multiple subnets on the same physical network" or something else, > I think. What terminology do other RFCs use (I'm pretty sure this is > described somewhere)? It would be better to be consistent. I like the term "link", but as you say, it's not in common usage for IPv4. Physical network has the problem that it's not very descriptive - what precisely is a physical network? I've added the following definition: "link" Any set of all network attachment points that will recieve a link-layer broadcast sent on any one of the attachment points. This term is used in DHCP because in some cases more than one IP subnet may be configured on a link. DHCP uses a local-network (all-ones) broadcast, which is not subnet-specific, and will therefore reach all nodes connected to the link, regardless of the IP subnet or subnets on which they are configured. A "link" is sometimes referred to as a broadcast domain or physical network segment. ...and I've adjusted the cases where the term "broadcast domain" is used to use "link" instead. > Presumably they already ignore the option per existing RFCs? I.e, it > seems odd to make it a requirement of *this* spec to specify behavior > on an implementation that "does not support" the option... I just copied that. It makes a certain amount of sense to say it - some implementations of DHCP clients log errors if they receive unknown options. Obviously this draft is not the place to fix that problem, but I don't think this wording causes any problems. > seems like MUST is too strong, and SHOULD would suffice. I.e, it might > be that a client understands the option, but doesn't actually want the > DHCP server to return such an option because it will ignore it or > something. The wording here has been changed per Stuart Cheshire's request. His concern was that the current wording meant his client had to stop supporting the Static Routes option (which was my intention). So this is no longer recommended. > Why this SHOULD? I.e., if it is not a MUST, the server can't count on > this being the case, so what is the benefit? True. Stuart pointed this out as well. It is now a MUST: The Classless Static Routes option code MUST appear in the parameter request list prior to both the Router option code and the Static Routes option code, if present. > My personal preference would be to allow extra the bits. It's not that > uncommon to provide a host address and a netmask to indicate a subnet > number. I.e., it's work to figure out which bits should be chopped off > and to actually set them to zero. Okay, I've changed the wording to read as follows: After deriving a subnet number and subnet mask from each destination descriptor, the DHCP client MUST set any bits in the subnet number that are zero in the subnet mask to zero. For example, if the server sends a route with a destination of 129.210.177.132 (hexadecimal 81D4B184) and a subnet mask of 255.255.255.128 (hexadecimal FFFFFF80), the client will install a route with a destination of 129.210.177.128 (hexadecimal 81D4B180). > This text could use a bit of tweaking. Note that whether an > implementation supports reassembly isn't relevant. I've reworded it a bit (partially at Stuart's request): Because a full routing table can be quite large, the standard 576 octet maximum size for a DHCP message may be too short to contain some legitimate Classless Static Route options. Because of this, clients implementing the Classless Static Route option SHOULD send a Maximum DHCP Message Size [2] option if the DHCP client's TCP/IP stack is capable of reassembling fragmented IP datagrams. In this case, the client SHOULD set the value of this option to at least the MTU of the interface that the client is configuring. The client MAY set the value of this option higher, up to the size of the largest UDP packet it is prepared to accept. (Note that the value specified in the Maximum DHCP Message Size option is the total maximum packet size, including IP and UDP headers.) > Seems like MAY should be SHOULD. There is no reason to include it in > this case. Right? Okay. I'd already changed the wording somewhat at Stuart's request - this represents a somewhat larger change, which Stuart may wish to contest: When a DHCP client requests the Classless Static Routes option and also requests either or both of the Router option and the Static Routes option, and the DHCP server is sending Classless Static Routes options to that client, the server SHOULD NOT include the Router or Static Routes options. > Needs an IANA considerations section so that IANA knows to assign a > code point. Okay: IANA Considerations This DHCP option will require the allocation of an option code in the list DHCP option codes that the IANA maintains. Thanks for all the comments! _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 28 14:39:22 2001 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 OAA22079; Fri, 28 Sep 2001 14:39:18 -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 OAA16121; Fri, 28 Sep 2001 14:37:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16093 for ; Fri, 28 Sep 2001 14:37:49 -0400 (EDT) Received: from extmail01m.raleigh.ibm.com (extmail01.raleigh.ibm.com [204.146.167.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22042 for ; Fri, 28 Sep 2001 14:37:43 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [192.168.1.108]) by extmail01m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id OAA30550; Fri, 28 Sep 2001 14:37:16 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id OAA27040; Fri, 28 Sep 2001 14:37:15 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA25641; Fri, 28 Sep 2001 14:34:51 -0400 Message-Id: <200109281834.OAA25641@rotala.raleigh.ibm.com> To: Keith Moore cc: dhcwg@ietf.org In-Reply-To: Message of "Thu, 27 Sep 2001 15:32:42 EDT." <200109271932.PAA20346@astro.cs.utk.edu> Date: Fri, 28 Sep 2001 14:34:51 -0400 From: Thomas Narten Subject: [dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Keith Moore writes: (in a message sent to the iesg) > The problem I have with this option is that it invites implementors > and network administrators to presume that a host's domain should be > tied to a host's location in the network - when these are intentionally, > and by design, entirely separate. For instance, a mobile computer user > who wishes DNS lookups to be performed relative to a particular domain > should not have this choice overridden by each POP to which he connects. > (The fact that protocol designers often try to use DNS lookups as a > means to discover topologically close services does not change this. > There is an inherent conflict between using DNS as a way to discover > services relative to a domain and using it as a way to discover > services relative to a network location, but the intent of DNS > clearly favors the former.) > Host DHCP implementations therefore should not blindly accept Domain > Search information from a DHCP server. Local configuration of any > DNS information (including not just search domains, but also DNS servers) > should override anything supplied by DHCP. > Keith I am sympathetic with your general point. I'll also note that this arguably applies to a number of other existing DHCP options. I don't believe right off that this point is explicitely addressed in the other cases either. 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? What do existing RFCs say about this point? Finally, what do you propose? I.e., "send text" :-) Would it suffice to add some language stating that in the case of this option, it should not override a manually configured search list? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 28 21:39:02 2001 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 ; 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 ; 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 From: John Schnizlein Subject: Re: [dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed Standard Cc: Keith Moore , dhcwg@ietf.org In-Reply-To: <200109281834.OAA25641@rotala.raleigh.ibm.com> References: 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: 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