idnits 2.17.1 draft-ietf-ipoib-dhcp-over-infiniband-06.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 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 7 longer pages, the longest (page 5) being 77 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 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 15 instances of too long lines in the document, the longest one being 7 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 2004) is 7339 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 215, but not defined == Unused Reference: 'RFC1542' is defined on line 231, but no explicit reference was found in the text == Unused Reference: 'RFC2855' is defined on line 236, 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: 5 errors (**), 0 flaws (~~), 7 warnings (==), 4 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 2004 March 2004 5 DHCP over InfiniBand 7 Status of this memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC 2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as Reference 20 material or to cite them other than as ``work in progress''. 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 This memo provides information for the Internet community. This 29 memo does not specify an Internet standard of any kind. 30 Distribution of this memo is unlimited. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 An InfiniBand network uses a link-layer addressing scheme that is 39 20-octets long. This is larger than the 16-octets reserved for the 40 hardware address in DHCP/BOOTP message. The above inequality imposes 41 restrictions on the use of the DHCP message fields when used over an 42 IP over InfiniBand(IPoIB) network. This document describes the use 43 of DHCP message fields when implementing DHCP over IPoIB. 45 1. Introduction 47 The Dynamic Host Configuration Protocol(DHCP) provides a framework 48 for passing configuration information to hosts on a TCP/IP network 49 [RFC2131]. DHCP is based on the Bootstrap Protocol (BOOTP) [RFC951] 50 adding the capability of automatic allocation of reusable network 51 addresses and additional configuration options [RFC2131,RFC2132]. 53 The DHCP server receives a broadcast request from the DHCP client. 54 The DHCP server uses the client interface's hardware-address to 55 unicast a reply back when the client doesn't yet have an IP address 56 assigned to it. The 'chaddr' field in the DHCP message carries the 57 client's hardware address. 59 The "chaddr" field is 16-octets in length. The IPoIB link-layer 60 address is 20-octets in length. Therefore the IPoIB link-layer 61 address will not fit in the "chaddr" field making it impossible for 62 the DHCP server to unicast a reply back to the client. 64 To ensure interoperability the usage of the fields and the method 65 for DHCP interaction must be clarified. This document describes the 66 IPoIB specific usage of some fields of DHCP. See [RFC2131] for the 67 mechanism of DHCP and the explanations of each field. 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [RFC2119]. 73 2. The DHCP over IPoIB mechanism 75 As is noted above, the link-layer address is unavailable to the DHCP 76 server because it is larger than the "chaddr" field length. 77 Therefore, a DHCP client MUST request that the server sends a 78 broadcast reply by setting the BROADCAST flag when IPoIB ARP is not 79 possible, i.e. in situations where the client does not know its IP 80 address. 82 RFC1542 notes that the use of a broadcast reply is discouraged. But 83 in the case of IPoIB this is a necessity. There is no option but to 84 broadcast back to the client since it is not possible to reply the 85 client's unicast address. To desynchronise broadcasts at subnet 86 startup, RFC2131 suggests that a client wait a random time (1 to 10 87 seconds) before initiating server discovery. The same timeout will 88 equally spread out the DHCP server broadcast responses generated due 89 to the use of the use of the BROADCAST bit. 91 The client hardware address, "chaddr", is unique in the subnet and 92 hence can be used to identify the client interface. But in the 93 absence of a unique chaddr the client-identifier must be used. 95 The DHCP protocol states that the "client identifier" option may be 96 used as the unique identifying value for the client. This value 97 must be unique within the subnet the client is a member of. 99 The client identifier option includes a type and identifier pair. 100 The identifier included in the client-identifier option may consist 101 of a hardware address or any other unique value such as the DNS name 102 of the client. When a hardware address is used, the type field 103 should be one of the ARP hardware types listed in [ARPPARAM]. 105 2.1 IPoIB specific usage of DHCP message fields 107 A DHCP client, when working over an IPoIB interface, MUST follow the 108 following rules: 110 "htype" (hardware address type) MUST be 32 [ARPPARAM] 112 "hlen" (hardware address length) MUST be 0. 114 "chaddr" (client hardware address) field MUST be zeroed. 116 "client identifier" option MUST be used in DHCP messages. 118 According to RFC2132 the "client identifier" option MAY consist of 119 any data, but IPoIB clients SHOULD use the format discussed below 120 for the client-identifier option. 122 Note: This document does not preclude the use of other "client 123 identifier" type, such as fully qualified domain 124 name(FQDN) or the EUI-64 value associated with the 125 interface. 127 2.1.1 Client-identifier values 129 Every IPoIB interface is associated with an identifier referred to 130 as the GID [IPoIB_ARCH]. A GID is formed by appending the port's 131 EUI-64 identifier to the InfiniBand subnet prefix. An invariant GID 132 is formed when the port's manufacturer assigned EUI-64 value is used 133 to form the GID. A port might have additional EUI-64 values assigned 134 to it by the subnet-manager(SM) [IBARCH]. Therefore a port can have 135 multiple GIDs associated with it. A GID is unique in the InfiniBand 136 fabric. 138 The GID is associated with a particular hardware port. The GID and a 139 QPN define an IPoIB interface at the port[IPOIB_ENCAP]. Therefore 140 an implementation could associate multiple IPoIB interfaces on the 141 same port by utilising a common GID but different QPNs. In such a 142 case the GID is shared between multiple interfaces, and therefore, 143 the "client identifier" formed from just the GID is no longer unique 144 in the IP subnet. 146 This is not an issue if the interfaces sharing the GID are in 147 different InfiniBand partitions, and thereby on different IPoIB 148 links, since the "client identifier" need only be unique within a 149 subnet. However, if the GID is shared by interfaces within the same 150 partition the implementation MUST ensure a unique client-identifier. 151 For example, a unique client-identifier may be formed by including 152 the QPN associated with the relevant IPoIB interface if the 153 implementation is designed to keep this association constant across 154 boots. Some other value unique to the implementation may also be 155 used for the same purpose. 157 If there is only one IPoIB interface associated with a particular 158 GID within a partition, then use of the GID is sufficient. 160 Since a port may be associated with multiple GIDs, multiple IPoIB 161 interfaces may exist on the same port while using a different GID 162 from among the GIDs associated with the port. In such a case too the 163 GID can form a unique "client identifier". 165 Therefore, one of the following formats SHOULD be used for the 166 client-identifier option. 168 1. If the QPN is used to distinguish between interfaces using the 169 same GID. 171 Code Len Type |<---------------- Client-Identifier -------------->| 172 +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ 173 | 61 | 21 | 32 | 20 octets(link-layer address) | 174 +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ 176 2. A unique value, other than the QPN, may be used to distinguish 177 between interfaces using the same GID. In this case a "type" 178 of 0 MUST be specified since the identifier is not an identifier 179 listed in ARPPARAM [RFC2132]. 181 Code Len Type |<---------------- Client-Identifier -------------->| 182 +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ 183 | 61 | 21 | 00 | Unique-value(4 octets)| 16 octet GID | 184 +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ 186 But if the GID is not shared with another IPoIB interface then there 187 is no need for another "unique-value". In such a case the GID 188 suffices by itself. 190 Code Len Type |<---------------- Client-Identifier -------------->| 191 +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ 192 | 61 | 21 | 00 | 00 (4 octets) | 16 octet GID | 193 +-----+-----+-----+-----+-----+-----+-----+-------------------....----+ 195 2.2 Use of the BROADCAST flag 197 A DHCP client on IPoIB MUST set the BROADCAST flag in DHCPDISCOVER 198 and DHCPREQUEST messages (and set "ciaddr" to zero) to ensure that 199 the server (or the relay agent) broadcasts its reply to the client. 201 Note: As described in [RFC2131], "ciaddr" MUST be filled in 202 with client's IP address during BOUND, RENEWING or 203 REBINDING state, therefore, the BROADCAST flag MUST NOT 204 be set. In these cases, the DHCP server unicasts DHCPACK 205 message to the address in "ciaddr". The link address 206 will be resolved by IPoIB ARP. 208 3. Security Considerations 210 RFC2131 describes the security considerations relevant to DHCP. This 211 document does not introduce any new issues. 213 4. Acknowledgement 215 This document borrows extensively from [RFC 2855]. Roy Larsen 216 pointed out the length discrepancy between the IPoIB link address 217 and DHCP's chaddr field. 219 References 221 [RFC2119] Key words for use in RFCs to Indicate Requirement Levels, 222 S. Bradner 224 [RFC2131] Dynamic Host Configuration Protocol, R. Droms 226 [RFC2132] DHCP Options and BOOTP Vendor Extensions, 227 S. Alexander, R. Droms 229 [RFC951] Bootstrap Protocol, B. Croft, J. Gilmore 231 [RFC1542] Clarifications and Extensions for the Bootstrap Protocol, 232 W. Wimer 234 [ARPPARAM] http://www.iana.org/numbers.html 236 [RFC2855] DHCP for IEEE 1394, K. Fujisawa 238 [IPoIB_ARCH] draft-ietf-ipoib-architecture-03.txt, V. Kashyap 240 [IPoIB_ENCAP] draft-ietf-ipoib-ip-over-infiniband-06.txt, 241 H.K. Jerry Chu, V. Kashyap 243 [IBARCH] InfiniBand Architecture Specification, www.infinibandta.org 245 Author's Address 247 Vivek Kashyap 249 15350, SW Koll Parkway 250 Beaverton, OR 97006 251 USA 252 Phone: +1 503 578 3422 253 EMail: vivk@us.ibm.com 255 Full Copyright Statement 257 Copyright (C) The Internet Society (2000). All Rights Reserved. 259 This document and translations of it may be copied and furnished 260 to others, and derivative works that comment on or otherwise 261 explain it or assist in its implementation may be prepared, 262 copied, published and distributed, in whole or in part, without 263 restriction of any kind, provided that the above copyright 264 notice and this paragraph are included on all such copies and 265 derivative works. However, this document itself may not be 266 modified in any way, such as by removing the copyright notice or 267 references to the Internet Society or other Internet 268 organizations, except as needed for the purpose of developing 269 Internet standards in which case the procedures for copyrights 270 defined in the Internet Standards process must be followed, or 271 as required to translate it into languages other than English. 273 The limited permissions granted above are perpetual and will not 274 be revoked by the Internet Society or its successors or assigns. 276 This document and the information contained herein is provided 277 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 278 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 279 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 280 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 281 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 282 PARTICULAR PURPOSE.