idnits 2.17.1 draft-ietf-ipoib-ip-over-infiniband-01.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 13 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 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 (May 20, 2002) is 8006 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: '15-0' is mentioned on line 158, but not defined == Missing Reference: '23-0' is mentioned on line 392, but not defined == Missing Reference: '127-96' is mentioned on line 394, but not defined == Missing Reference: '95-64' is mentioned on line 396, but not defined == Missing Reference: '63-32' is mentioned on line 398, but not defined == Missing Reference: '31-0' is mentioned on line 400, but not defined == Unused Reference: 'RFC2375' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'RFC1700' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 571, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Downref: Normative reference to an Informational RFC: RFC 2375 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' Summary: 11 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Vivek Kashyap 3 IBM 4 Expiration Date: November 20, 2002 5 H.K. Jerry Chu 6 Sun Microsystems 8 May 20, 2002 10 IP encapsulation and address resolution over InfiniBand networks 12 Status of this memo 14 This document is an Internet-Draft and is in full conformance 15 with all provisions of Section 10 of RFC 2026. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet- Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use 25 Internet-Drafts as Reference material or to cite them other 26 than as ``work in progress''. 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed 32 at http://www.ietf.org/shadow.html 34 This memo provides information for the Internet community. 35 This memo does not specify an Internet standard of any kind. 36 Distribution of this memo is unlimited. 38 Copyright Notice 40 Copyright (C) The Internet Society (2001). All Rights Reserved. 42 Abstract 44 This document specifies the frame format for transmission of 45 IP and ARP packets over InfiniBand networks. Unless explicitly 46 specified, the term 'IP' refers to both IPv4 and IPv6. The 47 term 'ARP' refers to all the ARP protocols/op-codes such as 48 ARP/RARP. This document also describes the method of forming 49 IPv6 link-local addresses, and the content of the 50 source/target link layer address option used in Neighbour 51 solicitation and advertisement, router advertisement, router 52 redirect and router solicitation on IPv6 over InfiniBand. 54 Table of Contents 56 1.0 Introduction 57 2.0 InfiniBand Datalink 58 2.1 IP Support on IPoIB Link 59 3.0 Frame Format 60 4.0 Maximum Transmission Unit 61 5.0 IPv6 Stateless Autoconfiguration 62 5.1 IPv6 Link Local Address 63 6.0 Address Mapping - Unicast 64 6.1 Link-Information 65 6.1.1 Link Layer Address/Hardware Address 66 6.1.2 Auxiliary Link Information 67 6.2 Address Resolution in IPv4 Subnets 68 6.3 Address Resolution in IPv6 Subnets 69 7.0 IANA Considerations 70 8.0 Security Considerations 71 9.0 Acknowledgements 72 10.0 References 73 11.0 Authors' Addresses 75 1.0 Introduction 77 The InfiniBand specification[IB_ARCH] can be found at 78 www.infinibandta.org. The document [IPoIB_ARCH] provides a 79 short overview of InfiniBand architecture along with 80 considerations for specifying IP over InfiniBand networks. The 81 document [IPoIB_MCAST] defines the configuration of IPoIB 82 links and the support of IP multicast over InfiniBand 83 networks. 85 The InfiniBand architecture(IBA) defines multiple modes of 86 transport over which IP may be implemented. The unreliable 87 datagram(UD) transport method best matches the needs of IP and 88 the need for universality in general as described 89 in [IPoIB_ARCH]. 91 This document specifies IPoIB over IB's unreliable 92 datagram(UD) mode. A separate document will describe the 93 implementation of IP subnets over IB's other transport 94 mechanisms. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 97 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described 99 in RFC 2119. 101 2.0 InfiniBand Datalink 103 The document [IPoIB_MCAST] defines the IPoIB link, its setup, 104 and IP multicast over InfiniBand in detail. The following 105 discussion gives a short overview. 107 An IB subnet is formed by a network of IB nodes interconnected 108 either directly or via IB switches. IB subnets may be 109 connected using IB routers to form a fabric made of multiple 110 IB subnets. Multiple IP subnets may be overlaid over this IB 111 cloud. The boundary of this IP subnet is arbitrary and not 112 associated with a physical demarcation. The IPoIB nodes that 113 are members of this subnet are interconnected by an abstract 114 'link'. The link is defined by its members and common 115 characteristics such as the P_Key, link MTU and Q_Key that are 116 defined per 'link'. 118 IPv4 defines a limited-broadcast address over the link. All 119 IPv4 hosts that are members of the IPv4 subnet are members of 120 this address. IPv6 defines a multicast address referred to as 121 the all-IP hosts address. IPoIB associates a multicast GID 122 with these addresses [IPoIB_MCAST]. This multicast GID will 123 henceforth be referred to as the broadcast-GID. The 124 broadcast-GID is required to be setup for an IPoIB subnet to 125 be formed. 127 Every IPoIB interface MUST join the InfiniBand multicast group 128 defined by the broadcast-GID. This operation returns the MTU 129 and the Q_Key associated with the IPoIB link. Thus the IPoIB 130 subnet (and the link) is formed by the IPoIB nodes joining the 131 broadcast GID. 133 The P_Key is a configuration parameter that must be known 134 before the broadcast-GID can be formed[IPoIB_MCAST]. 136 2.1 IP Support on IPoIB Link 138 The unreliable datagram (UD) mode of communication is 139 supported by all IB elements be they IB routers, HCAs or TCAs. 140 In addition to being the only universal transmission method it 141 supports multicasting, partitioning and a 32-bit 142 CRC [IB_ARCH]. Though multicasting support is optional in IB 143 fabrics, IPoIB architecture requires the participating 144 components to support it [IPoIB_MCAST]. 146 All IPoIB implementations MUST support IP over the unreliable 147 datagram (UD) transport mode of IBA. 149 3.0 Frame Format 151 All IP and ARP datagrams transported over InfiniBand are 152 prefixed by a 4-byte encapsulation header as illustrated 153 below. 155 +--------+--------+--------+--------+ 156 | | | 157 | 16-bits | 16 bits | 158 | type[15-0] | Reserved | 159 +-----------------+-----------------+ 161 Figure 1 163 The type field SHALL indicate the encapsulated protocol as per 164 the following table. 166 +----------+-------------+ 167 | Type | Protocol | 168 |------------------------| 169 | 0x800 | IPv4 | 170 |------------------------| 171 | 0x806 | ARP | 172 |------------------------| 173 | 0x8035 | RARP | 174 |------------------------| 175 | 0x86DD | IPv6 | 176 +------------------------+ 178 Table 1 180 These values are taken from the 'ETHER TYPE' numbers assigned 181 by [IANA]. Other network protocols, identified by different 182 values of 'ETHER TYPE', may use the encapsulation format 183 defined herein but such use is outside of the scope of this 184 document. 186 |<------ IB Frame headers -------->|<- Payload ->|<- IB trailers ->| 187 +-------+------+---------+---------+-------------+---------+-------+ 188 |Local | |Base |Datagram | | | | 189 |Routing| GRH* |Transport|Extended |4-byte header|Invariant|Variant| 190 |Header |Header|Header |Transport| + | CRC | CRC | 191 | | | |Header | IP/ARP | | | 192 +-------+------+---------+---------+-------------+---------+-------+ 194 Figure 2 196 Figure 2 depicts the IB frame encapsulating an IP/ARP 197 datagram. The InfiniBand specification requires the use of 198 Global Routing Header (GRH) [IPoIB_ARCH] when multicasting or 199 when an InfiniBand packet traverses from one IB subnet to 200 another through an IB router. Its use is optional when used 201 for unicast transmission between nodes within an IB subnet. 202 The IPoIB implementation MUST be able to handle packets 203 received with or without the use of GRH. 205 4.0 Maximum Transmission Unit 207 Every IP/ARP datagram includes a 4 byte encapsulation header 208 as defined above. Therefore the IP MTU can be found by 209 subtracting 4 from the IPoIB link MTU. 211 To illustrate the calculation of IP MTU the following table 212 lists some likely values : 214 IPoIB Link MTU IP MTU 216 4096 4092 217 2048 2044 218 1504 1500 219 1284 1280 221 The IPv4 MTU MUST NOT be set below 1500 bytes. The minimum 222 IPv6 MTU is 1280 bytes [RFC2373]. 224 IB links, switches and CAs support multiple MTUs (IB_MTU): 225 256, 512, 1024, 2048, 4096 bytes. The above conditions on IP 226 MTU require that IB components used in IPoIB subnets support a 227 minimum of 2048 byte MTUs. The IPoIB link MTU is set to the 228 MTU associated with the IB multicast group defined by the 229 broadcast-GID [IPoIB_MCAST]. 231 In IPv6 subnets the MTU may be reduced by a Router 232 Advertisement [RFC2461] containing an MTU option which 233 specifies a smaller MTU, or by manual configuration of each 234 node. If a Router Advertisement received on an IPoIB interface 235 has an MTU option specifying an MTU larger than the link MTU 236 or larger than a manually configured value, that MTU option 237 may be logged to system management but must be otherwise 238 ignored. 240 Similarly, the IPv4 MTU may also be reduced by manual 241 configuration of each node. 243 For purposes of this document, information received from DHCP 244 is considered "manually configured". 246 5.0 IPv6 Stateless Autoconfiguration 248 IB architecture associates an EUI-64 identifier termed the 249 GUID (Globally Unique Identifier) [IPoIB_ARCH, IB_ARCH] with 250 each port. The LID (16 bits) is unique within an IB subnet 251 only. 253 The interface identifier may be chosen from: 255 1) The EUI-64 compliant Globally unique 256 identifier(GUID) assigned by the manufacturer. 258 2) If the IPoIB subnet is fully contained within an IB 259 subnet any of the unique 16-bit LIDs of the port 260 associated with the IPoIB interface. 262 The LID values of a port may change after a 263 reboot/power-cycle of the IB node. Therefore, if a 264 persistent value is desired, it would be prudent to 265 not use the LID to form the interface identifier. 267 On the other hand, the LID provides an identifier 268 that can be used to create a more anonymous IPv6 269 address since the LID is not globally unique and is 270 subject to change over time. 272 It is RECOMMENDED that the link-local address be constructed 273 from the port's EUI-64 identifier as per the rules specified 274 in [RFC2373]. 276 The interface identifier may also be chosen as per the 277 guidelines specified in [RFC3041]. 279 5.1 IPv6 Link Local Address 281 The IPv6 link local address for an IPoIB interface is formed 282 in accordance with the guidelines in [RFC2373]. The link local 283 address is of the format: 285 10 bits 54 bits 64 bits 286 +----------+-----------------------+----------------------------+ 287 |1111111010| (zeros) | Interface Identifier | 288 +----------+-----------------------+----------------------------+ 290 Figure 2 292 6.0 Address Mapping - Unicast 294 Address resolution in IPv4 subnets is accomplished through 295 Address Resolution protocol (ARP)[RFC826]. It is accomplished 296 in IPv6 subnets using the Neighbor discovery 297 protocol[RFC2461]. 299 6.1 Link Information 301 An InfiniBand packet over the UD mode includes multiple 302 headers such as the LRH(local route header), GRH(global route 303 header), BTH(base transport header), DETH(datagram extended 304 header) as depicted in Figure 1 and specified in the 305 InfiniBand architecture[IB_ARCH]. All these headers comprise 306 the link-layer in an IPoIB link. 308 The parameters needed in these IBA headers constitute the 309 link-layer information that needs to be determined before an 310 IP packet may be transmitted across the IPoIB link. 312 The parameters that need to be determined are: 314 a) LID (local identifier) 316 The LID is always needed. A packet always includes the 317 LRH that is targeted at the remote node's LID, or an 318 IB router's LID to get to the remote node in another 319 IB subnet. 321 b) GID (global identifier) 323 The GID is not needed when exchanging information 324 within an IB subnet though it may be included in any 325 packet. It is an absolute necessity when transmitting 326 across the IB subnet since the IB routers use the GID 327 to correctly forward the packets. The source and 328 destination GIDs are fields included in the GRH. 330 The GID, if formed using the GUID, can be used to 331 unambiguously identify an endpoint. 333 c) QPN (queue pair number) 335 Every unicast UD communication is always directed to a 336 particular queue pair(QP) at the peer. 338 d) Q_Key 340 A Q_Key is associated with each unreliable datagram 341 QPN. The received packets must contain a Q_Key that 342 matches the QP's Q_Key to be accepted. 344 e) P_Key 346 A successful communication between two IB nodes using 347 UD mode can occur only if the two nodes have 348 compatible P_Keys. This is referred to as being in the 349 same partition[IB_ARCH]. P_Keys are checked at the 350 receiving channel adapter and may be optionally 351 checked at intermediate switches/IB routers. If the 352 P_Key in the packet does not match the expected P_Key 353 the packet is dropped. 355 f) SL (service level) 357 Every IBA packet contains an SL value. A path in IBA 358 is defined by the three-tuple (source LID, destination 359 LID, SL). The SL in turns is mapped to a virtual 360 lane(VL) at every xCA, switch that sends/forwards the 361 packet [IPoIB_ARCH]. Multiple SLs may be used between 362 two endpoints to provide for load-balancing, SLs may 363 be used for providing a QoS infrastructure, or may be 364 used to avoid deadlocks in the IBA fabric. 366 Another auxiliary piece of information, not included in the 367 IBA headers, is : 369 g) Path rate 371 The InfiniBand architecture defines multiple link 372 speeds. A higher speed transmitter can swamp 373 switches/xCAs. To avoid such congestion every source 374 transmitting at greater than 1x speeds is required to 375 determine the 'path rate' before the data may be 376 transmitted [IB_ARCH]. 378 6.1.1 Link Layer Address/Hardware Address 380 Though the list of information required for a successful 381 transmittal of an IPoIB packet is large not all the 382 information need be determined during the IP address 383 resolution process. 385 The IPoIB link-layer address used in the source/target 386 link-layer address option in IPv6 and the 'hardware address' 387 in IPv4/ARP has the same format. 389 The format is as described below: 391 +--------+--------+--------+--------+ 392 |Reserved| QPN[23-0] | 393 +--------+--------+--------+--------+ 394 | GID[127-96] | 395 + + 396 | GID[95-64] | 397 + + 398 | GID[63-32] | 399 + + 400 | GID[31-0] | 401 +--------+--------+--------+--------+ 403 Figure 3 405 a) Reserved Flags 407 These 8 bits are reserved for future use. These bits 408 MUST be set to zero on send and ignored on receive 409 unless specified differently in a future document. 411 b) Queue Pair Number (QPN) 413 Every unicast communication in IB architecture is 414 directed to a specific queue pair(QP)[IB_ARCH]. This 415 QP number is included in the link description. All IP 416 communication to the relevant IPoIB interface MUST be 417 directed to this QPN. In the case of IPv4 subnets the 418 address resolution protocol(ARP) reply packets are 419 also directed to the same QPN. 421 The choice of the QPN for IP/ARP communication is up 422 to the implementation. 424 c) Global Identifier (GID) 426 This is one of the Global Identifiers(GIDs)[IB_ARCH] 427 of the port associated with the IPoIB interface. IB 428 associates multiple GIDs with a port. It is 429 RECOMMENDED that the GID formed by the combination of 430 the IB subnet prefix and the port's GUID be included 431 in the link-layer/hardware address. 433 6.1.2 Auxiliary Link Information 435 The rest of the parameters are determined as follows: 437 a) Local Identifier(LID) 439 The method of determining the peer's LID is not 440 defined in this document. It is up to the 441 implementation to use any of the IBA approved methods 442 to determine the destination LID. One such method is 443 to use the GID determined during the address 444 resolution, to retrieve the associated LID from the IB 445 routing infrastructure or the SA. 447 It is the responsibility of the administrator to 448 ensure that the IB subnet(s) have unicast connectivity 449 between the IPoIB nodes. The GID exchanged between two 450 endpoints in a multicast message(ARP/ND) does not 451 guarantee the existence of a unicast path between the 452 two. This has to be ensured by the fabric 453 administrator. 455 There may be multiple LIDs, and hence paths, between 456 the endpoints. The criteria for selection of the LIDs 457 are beyond the scope of this document. 459 b) Q_Key 461 The Q_Key received on joining the broadcast-GID MUST 462 be used for all IPoIB communication over the 463 particular IPoIB link. 465 c) P_Key 467 The network administrator is required to setup an 468 IPoIB link by setting up an IB partition and assigning 469 it a unique P_Key[IPoIB_MCAST]. 471 Thus the P_Key to be used in the IP subnet is not 472 discovered but is a configuration parameter. 474 d) Service Level(SL) 476 The method of determining the SL is not defined in 477 this document. The SL is determined by any of the IBA 478 approved methods. 480 e) Path rate 482 The implementation must leverage IB methods to 483 determine the path rate as required. 485 6.2 Address Resolution in IPv4 Subnets 487 The ARP packet header is as defined in [RFC826]. The hardware 488 type is set to 32(decimal) as specified by Internet Assigned 489 Numbers Authority(IANA). The rest of the fields are used as 490 per RFC826. 492 16 bits: hardware type 493 16 bits: protocol 494 8 bits: length of hardware address 495 8 bits: length of protocol address 496 16 bits: ARP operation 498 The remaining fields in the packet hold the sender/target 499 hardware and protocol addresses. 501 [ sender hardware address ] 502 [ sender protocol address ] 503 [ target hardware address ] 504 [ target protocol address ] 506 The hardware address included in the ARP packet will be as 507 specified in section 6.1.1 and depicted in Figure 3. 509 The length of the hardware address used in ARP packet header 510 therefore is 20. 512 6.3 Address Resolution in IPv6 Subnets 514 The Source/Target Link-layer address option is used in Router 515 Solicit, Router advertisements, Redirect, Neighbour 516 Solicitation and Neighbour Advertisement messages when such 517 messages are transmitted on InfiniBand networks. 519 The source/target address option is specified as follows: 521 Type: 522 Source Link-layer address 1 523 Target Link-layer address 2 525 Length: 3 527 Link-layer address: 529 The link-layer address is as specified in section 530 6.1.1 and depicted in Figure 3. 532 7.0 IANA Considerations 534 To support ARP over InfiniBand a value for the Address 535 Resolution Parameter 'Number Hardware Type (hrd)' is required. 536 IANA has assigned the number '32' to indicate 537 InfiniBand[IANA_ARP]. 539 8.0 Security Considerations 541 This document specifies IP transmission over a multicast 542 network. Any network of this kind is vulnerable to a sender 543 claiming another's identity and forge traffic or eavesdrop. It 544 is the responsibility of the higher layers or applications to 545 implement suitable counter-measures if this is a problem. 547 9.0 Acknowledgements 549 The authors would like to thank Bruce Beukema, David Brean, 550 Dan Cassiday, Yaron Haviv, Thomas Narten, Erik Nordmark, Greg 551 Pfister, Jim Pinkerton, Renato Recio, Kevin Reilly, Madhu 552 Talluri and Satya Sharma for their suggestions and many 553 clarifications on the IBA specification. 555 10.0 References 557 [IB_ARCH] InfiniBand Architecture Specification, Volume 1.0a 558 www.infinibandta.org 560 [IPoIB_ARCH] draft-ietf-ipoib-architecture-01.txt 562 [IPoIB_MCAST] draft-ietf-ipoib-link-multicast-00.txt 564 [RFC2373] IP Version 6 Addressing Architecture 565 [RFC2375] IPv6 Multicast Address Assignments 567 [RFC826] An Ethernet Address Resolution Protocol 569 [RFC1700] Assigned Numbers. 571 [RFC2434] Guidelines for Writing an IANA Considerations Section in RFCs 573 [RFC2461] Neighbor Discovery for IP version 6 (IPv6) 575 [RFC3041] Extensions to IPv6 Address Autoconfiguration 577 [IANA] Internet assigned numbers authority, www.iana.org 579 [IANA_ARP] www.iana.org/assignments/arp-parameters 581 11.0 Authors' Address 583 Vivek Kashyap 585 15450, SW Koll Parkway 586 Beaverton, OR 97006 587 USA 589 Phone: +1 503 578 3422 590 Email: vivk@us.ibm.com 592 H.K. Jerry Chu 594 17 Network Circle, UMPK17-201 595 Menlo Park, CA 94025 596 USA 598 Phone: +1 650 786-5146 599 Email: jerry.chu@sun.com 601 Full Copyright Statement 603 Copyright (C) The Internet Society (2001). All Rights Reserved. 605 This document and translations of it may be copied and 606 furnished to others, and derivative works that comment on or 607 otherwise explain it or assist in its implementation may be 608 prepared, copied, published and distributed, in whole or in 609 part, without restriction of any kind, provided that the above 610 copyright notice and this paragraph are included on all such 611 copies and derivative works. However, this document itself may 612 not be modified in any way, such as by removing the copyright 613 notice or references to the Internet Society or other Internet 614 organizations, except as needed for the purpose of developing 615 Internet standards in which case the procedures for copyrights 616 defined in the Internet Standards process must be followed, or 617 as required to translate it into languages other than 618 English. 620 The limited permissions granted above are perpetual and will 621 not be revoked by the Internet Society or its successors or 622 assigns. 624 This document and the information contained herein is provided 625 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 626 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 627 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 628 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 629 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 630 PARTICULAR PURPOSE.