idnits 2.17.1 draft-ietf-ipoib-dhcp-over-infiniband-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 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 6 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 8 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 2002) is 8078 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) == Missing Reference: 'RFC 2855' is mentioned on line 197, but not defined == Unused Reference: 'RFC1542' is defined on line 213, but no explicit reference was found in the text == Unused Reference: 'RFC2855' is defined on line 218, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ARPPARAM' Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 3 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 2002 March 2002 5 DHCP over InfiniBand 7 Status of this memo 9 This document is an Internet-Draft and is in full conformance 10 with all provisions of Section 10 of RFC 2026. 12 Internet-Drafts are working documents of the Internet 13 Engineering Task Force (IETF), its areas, and its working 14 groups. Note that other groups may also distribute working 15 documents as Internet- Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use 20 Internet-Drafts as Reference material or to cite them other 21 than as ``work in progress''. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed 27 at http://www.ietf.org/shadow.html 29 This memo provides information for the Internet community. 30 This memo does not specify an Internet standard of any kind. 31 Distribution of this memo is unlimited. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 An InfiniBand network uses a link-layer addressing scheme that 40 is 20-bytes long. This is larger than the 16-bytes reserved for 41 the hardware address in DHCP/BOOTP message. The above 42 inequality imposes restrictions on the use of the DHCP message 43 fields when used over an IP over InfiniBand(IPoIB) network. 44 This document describes the use of DHCP message fields when 45 implementing DHCP over IPoIB. 47 1. Introduction 49 The Dynamic Host Configuration Protocol(DHCP) provides a 50 framework for passing configuration information to hosts on a 51 TCP/IP network [RFC2131]. DHCP is based on the Bootstrap 52 Protocol (BOOTP) [RFC951] adding the capability of automatic 53 allocation of reusable network addresses and additional 54 configuration options [RFC2131,RFC2132]. 56 The DHCP server receives a broadcast request from the DHCP 57 client. The DHCP server uses the client interface's 58 hardware-address to unicast a reply back when the client 59 doesn't yet have an IP address assigned to it. The 'chaddr' 60 field in the DHCP message carries the client's hardware 61 address. 63 The 'chaddr' field is 16-bytes in length. The IPoIB link-layer 64 address is 20-bytes in length. Therefore the IPoIB link-layer 65 address will not fit in the 'chaddr' field making it 66 impossible for the DHCP server to unicast a reply back to the 67 client. 69 To ensure interoperability the usage of the fields and the 70 method for DHCP interaction must be clarified. This document 71 describes the IPoIB specific usage of some fields of DHCP. See 72 [RFC2131] for the mechanism of DHCP and the explanations of 73 each field. 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 76 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 77 "OPTIONAL" in this document are to be interpreted as described 78 in RFC 2119 [RFC2119]. 80 2. The DHCP over IPoIB mechanism 82 As noted above, because of the link-layer address length being 83 larger than the 'chaddr' field length the link-layer address 84 is unavailable to the DHCP server. Therefore, a DHCP client 85 MUST request that the server sends a broadcast reply by 86 setting the BROADCAST flag when IPoIB ARP is not possible i.e. 87 in situations where the client does not know its IP address. 89 RFC1542 notes that the use of a broadcast reply is discouraged 90 but in the case of IPoIB this is a necessity. There is no 91 option but to broadcast back to the client since it is not 92 possible to reply the client's unicast address. To 93 desynchronise broadcasts at subnet startup, the RFC2131 94 suggests that a client wait a random time (1 to 10 seconds) 95 before initiating server discovery. The same timeout will 96 equally spread out the DHCP server broadcast responses 97 generated due to the use of the use of the BROADCAST bit. 99 The client hardware address, 'chaddr', is unique in the subnet 100 and hence can be used to identify the client interface. But in 101 the absence of a unique chaddr the client-identifier must be 102 used. 104 The DHCP protocol states that the 'client identifier' option 105 may be used as the unique identifying value for the client. 106 This value must be unique within the subnet the client is a 107 member of. The client-identifier may consist of the hardware 108 address or any other unique value such as the DNS name of the 109 client. The client-identifier itself is not interpreted by the 110 server. It is treated as a opaque value. 112 2.1 IPoIB specific usage of DHCP message fields 114 A DHCP client, when working over an IPoIB interface, MUST 115 follow the following rules: 117 'htype' (hardware address type) MUST be 32 [ARPPARAM] 119 'hlen' (hardware address length) MUST be 0. 121 The 'chaddr' (client hardware address) field MUST be zeroed. 122 The server and the relay agent MUST ignore 'chaddr' on 123 receipt. 125 The 'client identifier' option MUST be used in DHCP messages. 126 'client identifier' option MAY consist of any data. 128 2.1.1 A unique 'client-identifier' 130 The format of the 'client-identifier' option[RFC2132] is as 131 defined below: 133 Code Len Type Client-Identifier 134 +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ 135 | 61 | 21 | 32 |Interface-id (4 bytes) | GID (16 bytes) | 136 +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ 138 Every IPoIB interface is associated with an identifier 139 referred to as the GID [IPoIB_ARCH]. The GID is unique in the 140 InfiniBand fabric. An invariant GID is formed by appending the 141 port's EUI-64 identifier to the InfiniBand subnet prefix. 143 The GID is associated with a particular hardware port. The GID 144 and a QPN define an IPoIB interface at the port. Therefore an 145 implementation may associate multiple IPoIB interfaces on the 146 same port. It is up to the implementation to ensure a unique 147 client-identifier when multiple IPoIB interfaces are defined 148 over the same port and same GID. A unique, invariant 149 'interface-id' value be included in addition to the GID to 150 achieve this. 152 Note: a port may be associated with multiple GIDs. Therefore, 153 multiple IPoIB interfaces may exist on the same port while 154 using a different GID from among the GIDs associated with the 155 port. 157 A unique interface-id may be formed by including the QPN 158 associated with the relevant IPoIB interface if the 159 implementation is designed to keep this association constant 160 across boots. A timestamp or some other value unique to the 161 implementation may also be used for the same purpose. 163 If there is only one IPoIB interface associated with a 164 particular GID, then use of the GID with the 'interface-id' 165 zeroed is sufficient. By default, an implementation zeroes out 166 the interface-id field in the client identifier described 167 above. 169 This document does not preclude the use of other 'client 170 identifier' type, such as fully qualified domain name(FQDN) or 171 the EUI-64 value associated with the interface. 173 2.2 Use of the BROADCAST flag 175 A DHCP client on IPoIB SHOULD set a BROADCAST flag in 176 DHCPDISCOVER and DHCPREQUEST messages (and set 'ciaddr' to 177 zero) to ensure that the server (or the relay agent) 178 broadcasts its reply to the client. 180 Note: As described in [RFC2131], 'ciaddr' MUST be filled in 181 with client's IP address during BOUND, RENEWING or REBINDING 182 state, therefore, the BROADCAST flag MUST NOT be set. In these 183 cases, the DHCP server unicasts DHCPACK message to the address 184 in 'ciaddr'. The link address will be resolved by IPoIB ARP. 186 3. Security Considerations 188 DHCP currently provides no authentication or security 189 mechanisms. Potential exposures to attack are discussed 190 in section 7 of the DHCP protocol specification [RFC2131]. 192 A malicious client can falsify the client-identifier, 193 thus masquerading as another client. 195 4. Acknowledgement 197 This document borrows extensively from [RFC 2855]. Roy Larsen 198 pointed out the length discrepancy between the IPoIB link 199 address and DHCP's chaddr field. 201 References 203 [RFC2119] Key words for use in RFCs to Indicate Requirement Levels 204 S, Bradner 206 [RFC2131] Dynamic Host Configuration Protocol, R. Droms 208 [RFC2132] DHCP Options and BOOTP Vendor Extensions, 209 S. Alexander, R. Droms 211 [RFC951] Bootstrap Protocol, B. Croft, J. Gilmore 213 [RFC1542] Clarifications and Extensions for the Bootstrap Protocol 214 W. Wimer 216 [ARPPARAM] http://www.iana.org/numbers.html 218 [RFC2855] DHCP for IEEE 1394, K. Fujisawa 220 [IPoIB_ARCH] draft-ietf-ipoib-architecture-01.txt, V. Kashyap 222 [IPoIB_ENCAP] draft-ietf-ipoib-ip-over-infiniband-00.txt, 223 V. Kashyap, H.K. Jerry Chu 225 Author's Address 227 Vivek Kashyap 229 IBM 230 15450, SW Koll Parkway 231 Beaverton 232 OR 97006 234 Phone: +1 503 578 3422 235 EMail: vivk@us.ibm.com 237 Full Copyright Statement 239 Copyright (C) The Internet Society (2000). All Rights Reserved. 241 This document and translations of it may be copied and furnished to 242 others, and derivative works that comment on or otherwise explain it 243 or assist in its implementation may be prepared, copied, published 244 and distributed, in whole or in part, without restriction of any 245 kind, provided that the above copyright notice and this paragraph are 246 included on all such copies and derivative works. However, this 247 document itself may not be modified in any way, such as by removing 248 the copyright notice or references to the Internet Society or other 249 Internet organizations, except as needed for the purpose of 250 developing Internet standards in which case the procedures for 251 copyrights defined in the Internet Standards process must be 252 followed, or as required to translate it into languages other than 253 English. 255 The limited permissions granted above are perpetual and will not be 256 revoked by the Internet Society or its successors or assigns. 258 This document and the information contained herein is provided on an 259 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 260 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 261 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 262 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 263 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 265 -- 266 Vivek Kashyap 267 Linux Technology Center, IBM 268 kashyapv@us.ibm.com 269 vivk@us.ibm.com 270 503 578 3422 (o)