idnits 2.17.1 draft-ietf-ipoib-dhcp-over-infiniband-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 12. -- Found old boilerplate from RFC 3978, Section 5.5 on line 198. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 222. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 190), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 30. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2005) is 6979 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IBARCH' is defined on line 161, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ARPPARAM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IBARCH' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Vivek Kashyap 2 IBM 3 Expiration Date: September 2005 March 2005 5 DHCP over InfiniBand 7 Status of this memo 9 By submitting this Internet-Draft, I certify that any applicable 10 patent or other IPR claims of which I am aware have been disclosed, 11 or will be disclosed, and any of which I become aware will be 12 disclosed, in accordance with RFC 3668. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright (C) The Internet Society (2001). All Rights Reserved. 32 Abstract 34 An InfiniBand network uses a link-layer addressing scheme that is 35 20-octets long. This is larger than the 16-octets reserved for the 36 hardware address in DHCP/BOOTP message. The above inequality imposes 37 restrictions on the use of the DHCP message fields when used over an 38 IP over InfiniBand (IPoIB) network. This document describes the use 39 of DHCP message fields when implementing DHCP over IPoIB. 41 1. Introduction 43 The Dynamic Host Configuration Protocol (DHCP) provides a framework 44 for passing configuration information to hosts on an IP network 45 [RFC2131]. DHCP is based on the Bootstrap Protocol (BOOTP) [RFC951] 46 adding the capability of automatic allocation of reusable network 47 addresses and additional configuration options [RFC2131,RFC2132]. 49 The DHCP server receives a broadcast request from the DHCP client. 50 The DHCP server uses the client interface's hardware-address to 51 unicast a reply back when the client doesn't yet have an IP address 52 assigned to it. The "chaddr" field in the DHCP message carries the 53 client's hardware address. 55 The "chaddr" field is 16-octets in length. The IPoIB link-layer 56 address is 20-octets in length. Therefore the IPoIB link-layer 57 address will not fit in the "chaddr" field making it impossible for 58 the DHCP server to unicast a reply back to the client. 60 To ensure interoperability the usage of the fields and the method 61 for DHCP interaction must be clarified. This document describes the 62 IPoIB specific usage of some fields of DHCP. See [RFC2131] for the 63 mechanism of DHCP and the explanations of each field. 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 2. The DHCP over IPoIB mechanism 71 As described above, the link-layer address is unavailable to the 72 DHCP server because the link-layer address is larger than the 73 "chaddr" field length. As a result the server cannot unicast its 74 reply back to the client. Therefore, a DHCP client MUST request 75 that the server sends a broadcast reply by setting the BROADCAST 76 flag when IPoIB ARP is not possible, i.e. in situations where the 77 client does not know its IP address. 79 [RFC1542] notes that the use of a broadcast reply is discouraged. 80 But in the case of IPoIB this is a necessity because the server does 81 not receive the link-layer address. To desynchronise broadcasts at 82 subnet startup, [RFC2131] suggests that a client wait a random time 83 (1 to 10 seconds) before initiating server discovery. The same 84 timeout will equally spread out the DHCP server broadcast responses 85 generated due to the use of the use of the BROADCAST bit. 87 The client hardware address, "chaddr", is unique in the subnet and 88 hence can be used to identify the client interface. But in the 89 absence of a unique "chaddr", another unique client identifier must 90 be used. 92 The DHCP protocol states that the "client-identifier" option may be 93 used as the unique identifying value for the client [RFC2132]. This 94 value must be unique within the subnet the client is a member of. 96 The "client-identifier" option includes a type and identifier pair. 97 The identifier included in the "client-identifier" option may 98 consist of a hardware address or any other unique value such as the 99 DNS name of the client. When a hardware address is used, the type 100 field should be one of the ARP hardware types listed in [ARPPARAM]. 102 2.1 IPoIB specific usage of DHCP message fields 104 A DHCP client, when working over an IPoIB interface, MUST follow the 105 following rules: 107 "htype" (hardware address type) MUST be 32 [ARPPARAM] 109 "hlen" (hardware address length) MUST be 0. 111 "chaddr" (client hardware address) field MUST be zeroed. 113 "client-identifier" option MUST be used in DHCP messages. 115 The "client-identifier" used in DHCP messages MUST conform to 116 [DHC_3315id]. 118 2.2 Use of the BROADCAST flag 120 A DHCP client on IPoIB MUST set the BROADCAST flag in DHCPDISCOVER 121 and DHCPREQUEST messages (and set "ciaddr" to zero) to ensure that 122 the server (or the relay agent) broadcasts its reply to the client. 124 Note: As described in [RFC2131], "ciaddr" MUST be filled in 125 with client's IP address during BOUND, RENEWING or 126 REBINDING state, therefore, the BROADCAST flag MUST NOT 127 be set. In these cases, the DHCP server unicasts DHCPACK 128 message to the address in "ciaddr". The link address 129 will be resolved by ARP. 131 3. Security Considerations 133 [RFC2131] describes the security considerations relevant to DHCP. 134 This document does not introduce any new issues. 136 4. Acknowledgement 138 This document borrows extensively from [RFC2855]. Roy Larsen 139 pointed out the length discrepancy between the IPoIB link address 140 and DHCP's "chaddr" field. 142 5. References 144 5.1 Normative 146 [RFC2119] Key words for use in RFCs to Indicate Requirement Levels, 147 S. Bradner 149 [RFC2131] Dynamic Host Configuration Protocol, R. Droms 151 [RFC2132] DHCP Options and BOOTP Vendor Extensions, 152 S. Alexander, R. Droms 154 [RFC951] Bootstrap Protocol, B. Croft, J. Gilmore 156 [IPoIB_ENCAP] draft-ietf-ipoib-ip-over-infiniband-09.txt, 157 H.K. Jerry Chu, V. Kashyap 159 [ARPPARAM] http://www.iana.org/numbers.html 161 [IBARCH] InfiniBand Architecture Specification, 162 www.infinibandta.org/specs 164 [IPoIB_ARCH] draft-ietf-ipoib-architecture-04.txt, V. Kashyap 166 [DHC_3315id] draft-ietf-dhc-3315id-for-v4-04.txt, 167 T. Lemon, B. Sommerfeld 169 5.2 Informative 171 [RFC2855] DHCP for IEEE 1394, K. Fujisawa 173 [RFC1542] Clarifications and Extensions for the Bootstrap Protocol, 174 W. Wimer 176 6. Author's Address 178 Vivek Kashyap 180 15350, SW Koll Parkway 181 Beaverton, OR 97006 182 USA 183 phone: +1 503 578 3422 184 email: vivk@us.ibm.com 186 Full Copyright Statement 188 Copyright (C) The Internet Society (2004). This document is subject 189 to the rights, licenses and restrictions contained in BCP 78, and 190 except as set forth therein, the authors retain all their rights. 192 This document and the information contained herein are provided on 193 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 194 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 195 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 196 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 197 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 198 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 200 Intellectual Property Statement 202 The IETF takes no position regarding the validity or scope of any 203 Intellectual Property Rights or other rights that might be claimed 204 to pertain to the implementation or use of the technology described 205 in this document or the extent to which any license under such 206 rights might or might not be available; nor does it represent that 207 it has made any independent effort to identify any such rights. 208 Information on the procedures with respect to rights in RFC 209 documents can be found in BCP 78 and BCP 79. 211 Copies of IPR disclosures made to the IETF Secretariat and any 212 assurances of licenses to be made available, or the result of an 213 attempt made to obtain a general license or permission for the use 214 of such proprietary rights by implementers or users of this 215 specification can be obtained from the IETF on-line IPR repository 216 at http://www.ietf.org/ipr. 218 The IETF invites any interested party to bring to its attention any 219 copyrights, patents or patent applications, or other proprietary 220 rights that may cover technology that may be required to implement 221 this standard. Please address the information to the IETF at ietf- 222 ipr@ietf.org. 224 Acknowledgment 226 Funding for the RFC Editor function is currently provided by the 227 Internet Society.