idnits 2.17.1 draft-ietf-ipoib-link-multicast-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: It is up to the network administrator to select a link MTU to use when configuring an IPoIB link. The link MTU SHALL not be greater than the maximum payload size of any CA or switch connected to the IPoIB link. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note also that in case an IPoIB link spans more than one IB subnet, the IPoIB link MTU MUST not be set to greater than the path MTU of any path connecting two nodes in the same IB partition. It is up to the network administrator to determine the appropriate path MTU value that will work for any node in the same IPoIB link. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2373 (ref. 'AARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2461 (ref. 'DISC') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'IBTA' ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT H.K. Jerry Chu 3 Sun Microsystems 4 Vivek Kashyap 5 IBM 6 Expires: July, 2002 January, 2002 8 IP link and multicast over InfiniBand networks 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 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 (date). All Rights Reserved. 32 Abstract 34 This document specifies a method for setting up IP subnets and 35 multicast services over InfiniBand(TM) networks. Discussions in this 36 document are applicable to both IPv4 and IPv6, unless explicitly 37 specified. A separate document will cover unicast and encapsulation 38 of IP datagrams over InfiniBand networks. 40 1. Introduction 42 InfiniBand Architecture (IBA) defines four layers of network services 43 corresponding to layer one through layer four of the OSI reference 44 model. For the purpose of running IP over an InfiniBand (IB) 45 network, the IB network and all its link, network, and transport 46 layers collectively constitute the data link layer to the IP stack. 48 An IP network is often divided into many subnets connected by IP 49 routers. Subnetting allows the containment of broadcast traffic 50 within a single subnet. It also provides certain degree of isolation 51 between nodes on different subnets. The latter may be an important 52 consideration for administration purpose. 54 This document will focus on all the steps required to lay out an IP 55 network on top of an IB network. It will describe all the elements an 56 IP over InfiniBand (IPoIB) link consists of, how to configure its 57 associated link attributes, and how to set up basic broadcast and 58 multicast services on an IPoIB link. 60 2. Terminology 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 3. Basic IPoIB Transport - Unreliable Datagram 68 InfiniBand defines four types of transport services [IBTA]. They are 69 reliable connection, unreliable connection, reliable datagram, 70 unreliable datagram. IBA also defines a special raw datagram service 71 for encapsulation purpose. Both unreliable datagram and raw datagram 72 define support for multicast. They provide the basic transport 73 mechanism that best matches the IP datagram paradigm. 75 IB unreliable datagram provides many additional transport features 76 such as the partition key (P_Key) protection, multiple queue pairs 77 (QPs), and Q_Key protection. Moreover, it requires a 32-bit invariant 78 CRC checksum, which provides a much stronger protection against data 79 corruption, compared with the 16-bit CRC that a raw datagram carries. 81 For these reasons, IB unreliable datagram is considered to be a much 82 better choice as the basic IPoIB transport than the raw datagram, and 83 is chosen as the default IPoIB transport mechanism for the rest of 84 discussions in this document. 86 An IB unreliable datagram contains the following headers: 88 o Local Route Header (LRH) - provides IB link-layer addressing 89 information. An IB link layer address is based on a 16-bit 90 identifier called Local Identifier (LID), and is used by IB 91 switches to relay packets within an IB subnet. 93 o Global Route Header (GRH) - provides routing information for IB 94 routers to relay packets between IB subnets inside an IB fabric. 95 GRH is only required for all multicast packets and any unicast 96 packet that is destined to a node in a different IB subnet. GRH 97 carries an IB network-layer address, which is an 128-bit 98 identifier called Global Identifier (GID) that closely mimics IPv6 99 addressing architecture [AARCH]. 101 o Base Transport Header (BTH) - provides various information, 102 including P_Key, destination queue pair number (QPN) for IB 103 transport services. 105 o Datagram Extended Header (DETH) - provides additional IB 106 information such as Q_Key, source queue pair number for datagram 107 services. 109 From the perspective of IP over IB encapsulation, all the above IB 110 headers are considered as link layer encapsulation for IP datagrams. 112 4. IB Multicast Architecture 114 IBA defines two layers of multicast services. Its link layer uses 115 multicast LIDs (MLIDs), which are allocated by the Subnet Manager 116 (SM) and fall in the range between 0xC0000 to 0xFFFE (approximately 117 16k). MLIDs are used by IB switches to program their multicast 118 forwarding tables. An IB switch implementation may support much fewer 119 MLIDs in its forwarding table though. 121 IB network layer uses multicast GIDs (MGIDs), which closely resemble 122 IPv6 multicast addresses [AARCH] as shown in the following. 124 | 8 | 4 | 4 | 112 bits | 125 +------ -+----+----+---------------------------------------------+ 126 |11111111|flgs|scop| group ID | 127 +--------+----+----+---------------------------------------------+ 129 11111111 at the start of the address identifies the address as 130 being a multicast address. 132 +-+-+-+-+ 133 flgs is a set of 4 flags: |0|0|0|T| 134 +-+-+-+-+ 136 The high-order 3 flags are reserved, and must be initialized to 137 0. 139 T = 0 indicates a permanently-assigned ("well-known") multicast 140 address, assigned by the global internet numbering authority. 142 T = 1 indicates a non-permanently-assigned ("transient") 143 multicast address. 145 scop is a 4-bit multicast scope value used to limit the scope of 146 the multicast group. The values are: 148 0 reserved 149 1 node-local scope 150 2 link-local scope 151 3 (unassigned) 152 4 (unassigned) 153 5 site-local scope 154 6 (unassigned) 155 7 (unassigned) 156 8 organization-local scope 157 9 (unassigned) 158 A (unassigned) 159 B (unassigned) 160 C (unassigned) 161 D (unassigned) 162 E global scope 163 F reserved 165 group ID identifies the multicast group, either permanent or 166 transient, within the given scope. 168 MGIDs are mainly used by IB routers when forwarding multicast packets 169 to remote IB subnets that are part of a multicast forwarding tree. 170 Since every IB multicast packet is required to carry both LRH and 171 GRH, a valid MGID and a valid MLID are both needed before a valid IB 172 multicast packet can be constructed. 174 An IB multicast group is uniquely identified by a valid MGID. Before 175 a MGID can be used within an IB subnet, either as a destination 176 address of a multicast packet, or representing a multicast group that 177 an IB node can join, a "MCGroupRecord" corresponding to the MGID must 178 be created through the Subnet Administrator (SA). Besides the MGID, 179 the creator must supply values of the path MTU, Q_Key, TClass, 180 FlowLabel, HopLimit that are appropriate for all the potential 181 clients of the multicast group to use. In return, SA will allocate a 182 MLID to be used by switches in the local IB subnet. 184 Note that MLIDs are allocated and managed by SM when new MGIDs are 185 created though the creation of MCGroupRecords. The number of valid 186 MLIDs that are available in a given IB subnet is limited by the 187 implementation-dependent size of multicast forwarding table of IB 188 switches. Since the number can be small, reuses of MLIDs for MGIDs 189 may be inevitable. Implementation should nevertheless avoid sharing 190 the same MLID among high volume multicast groups in order to reduce 191 software filtering overhead and attain higher efficiency. 193 Unreliable multicast is defined by IBA as an optional functionality 194 for channel adaptors (CAs) and switches. In today's IP technology, 195 link multicast has become an indispensable function for better 196 supporting a modern IP network. For this reason, it is required that 197 an IPoIB fabric supports multicast. This includes all the CAs and 198 switches that make up an IP network. 200 5. IB Links vs IPoIB Links 202 A link segment on top of which an IP subnet can be configured is 203 defined in [IPV6] as a communication facility or medium over which 204 nodes can communicate at the "link" layer. For most types of 205 communication media, the boundary between different data link 206 segments follows the physical topology of the network connectivity, 207 and is pretty obvious. E.g. an Ethernet network connected by 208 switches, hubs, or bridges usually forms a single link segment and 209 broadcast/multicast domain. Different Ethernet segments can be 210 connected by IP routers at the network layer. 212 InfiniBand defines its own link-layer and subnets consisting of nodes 213 connected by IB switches. However, the IPoIB link boundary needs not 214 follow the IB link boundary. Nodes residing on different IB subnets 215 can still communicate directly with one another through IB routers at 216 the InfiniBand network layer. The same applies to multicast as well. 217 I.e. nodes on the same IB subnet can exchange multicast packets with 218 one another all within the same subnet through the IB link multicast 219 facility. But even nodes on different IB subnets can still exchange 220 multicast packets with one another using IB network-layer multicast. 222 The ultimate requirement for two nodes in the same IB fabric to 223 communicate at the IB level, besides the physical connectivity, is a 224 common P_Key. 226 Partitioning in IB provides an isolation mechanism among nodes in an 227 IB fabric, much like VLANs in an Ethernet network. Each port of an 228 endnode contains a P_Key table of all the valid P_Keys the port is 229 allowed to use. The P_Key table is set up by the SM of the local IB 230 subnet. Each QP is programmed with a P_Key from the local P_Key 231 table. This P_Key is carried in the BTH of all the outgoing packets 232 from the QP, and is used to compare against the P_Key in the BTH of 233 all the incoming packets to the QP. Reception of an invalid P_Key 234 causes the packet to be discarded. IB switches may optionally enforce 235 partition checking too. 237 Therefore P_Key and IB partition are the most natural choice for 238 defining IPoIB link boundary. It also affords much flexibility to the 239 network administrators when different links are set up in a large 240 network. This is very similar to VLANs in Ethernet. 242 6. Setting up an IPoIB Link 244 A network administrator defines an IPoIB link by setting up an IB 245 partition and assigning it a unique P_Key. An IB partition may or may 246 not span multiple IB subnets. But whether it does or not is mostly 247 irrelevant to IPoIB. 249 Each node attached to the IB partition MUST have one of its CA 250 assigned the P_Key to use. 252 Once an IB partition is established for IPoIB use, the link MTU and 253 Q_Key are two other important attributes that must be chosen before 254 the IPoIB link can be configured. 256 6.1 Maximum Transmission Unit 258 IB defines five permissible maximum payload sizes. They are 256, 512, 259 1024, 2048 and 4096 bytes. [IPV6] requires a link MTU of 1280 bytes 260 or greater. This leaves only 2048 and 4096 bytes as two acceptable 261 choices for IPv6. Channel adaptors supporting a maximum payload size 262 less than the minimal MTU requirement can still expose an acceptable 263 link MTU to IP through an adaptation layer that fragments larger 264 messages into smaller IB packets, and reassembles them on the 265 receiving end. But this must be done in a way that is completely 266 transparent to the IP stack. 268 It is up to the network administrator to select a link MTU to use 269 when configuring an IPoIB link. The link MTU SHALL not be greater 270 than the maximum payload size of any CA or switch connected to the 271 IPoIB link. 273 In general a larger link MTU can potentially offer a better 274 throughput performance. The caveat is that once a link MTU is chosen 275 for a given IPoIB link, nodes connected by CAs of a smaller maximum 276 payload size won't be able to join the link unless the whole link and 277 all the nodes attached to it are reconfigured to use a smaller MTU. 279 Note that the above discussion assumes that IP datagrams are fully 280 encapsulated in the payload of IB unreliable datagrams. The actual 281 MTU size, i.e., the payload size available for IP datagrams to use, 282 may be slightly smaller. This will depend on the actual IPoIB 283 encapsulation scheme, which will be covered in a separate document. 285 Note also that in case an IPoIB link spans more than one IB subnet, 286 the IPoIB link MTU MUST not be set to greater than the path MTU of 287 any path connecting two nodes in the same IB partition. It is up to 288 the network administrator to determine the appropriate path MTU value 289 that will work for any node in the same IPoIB link. 291 6.2. IPoIB Link Q_Key 293 A Q_Key is programmed by the source QP in every IB datagram, and is 294 verified by the destination QP against the Q_Key it has been 295 assigned. A Q_Key violation will cause the offending datagram to be 296 dropped, and a Q_Key violation trap to be raised. 298 A Q_Key must be selected to be used by all the QPs attached to an 299 IPoIB link. It is recommended that a controlled Q_Key be used with 300 the high order bit set. This is to prevent non-privileged software 301 from fabricating and sending out bogus IP datagrams. All QPs 302 configured to use on a given IPoIB link SHALL be assigned the same 303 per-link Q_Key. 305 6.3 Other Link Attributes 307 TClass, FlowLabel, and HopLimit are three other attributes that are 308 required for an IPoIB link covering more than a single IB subnet. 309 The selection of these values are implementation dependent. But it 310 must take into account the topology of IB subnets comprising the 311 IPoIB link to ensure successful communication between any two nodes 312 in the same IPoIB link. 314 7. The IPoIB All-Node Multicast and Broadcast Group 316 Once an IB partition is created with link attributes identified for 317 an IPoIB link, the network administrator must create a special IB 318 multicast group for every node on the IPoIB link to join. This is 319 achieved through the creation of "MCGroupRecord" in each IB subnet 320 that the IB partition encompasses, as described in section 4 above. 322 The MGID will have the P_Key of the IB partition that defines the 323 IPoIB link embedded in it. A special signature is also embedded to 324 identify the MGID for IPoIB use only. For IPv4 over IB, the signature 325 will be "0x401B". For IPv6 over IB, the signature will be "0x601B". 327 For an IPv4 subnet, the MGID for this special IB multicast group 328 SHALL have the following format: 330 | 8 | 4 | 4 | 16 bits | 16 bits | 48 bits | 32 bits | 331 +--------+----+----+-----------------+---------+----------+---------+ 332 |11111111|0001|scop||< P_Key >|00.......0|| 333 +--------+----+----+-----------------+---------+----------+---------+ 334 For an IPv6 subnet, the format of the MGID SHALL look like this: 336 | 8 | 4 | 4 | 16 bits | 16 bits | 80 bits | 337 +--------+----+----+-----------------+---------+--------------------+ 338 |11111111|0001|scop||< P_Key >|000.............0001| 339 +--------+----+----+-----------------+---------+--------------------+ 341 As for the scop bits, if the IPoIB link is fully contained within a 342 single IB subnet, the scop bits SHALL be set to 2 (link-local). 343 Otherwise the scope will be set higher. 345 A MCGroupRecord will be created with all the IPoIB link attributes 346 described before, including the link MTU, Q_Key, TClass, FlowLabel, 347 and HopLimit. When a node is attached to an IPoIB link identified by 348 a P_Key, it must look for a special, all-node multicast/broadcast 349 group to join. This is done by constructing the MGID with the link 350 P_Key and the IPoIB signature. The node SHOULD always look for a MGID 351 of a link-local scope first before attempting one with a greater 352 scope. 354 Once the right MGID and MCGroupRecord are identified, the local node 355 SHOULD use the link MTU recorded in the MCGroupRecord. It MUST accept 356 a smaller MTU if one is advertised through the link MTU option of a 357 router advertisement [DISC]. 359 In case the link MTU is greater than the maximum payload size that 360 the local HCA can support, the node can not join the IPoIB link and 361 operate as an IP node. 363 After the right MTU is determined, the local node must join the 364 special all-node multicast/broadcast group by calling the SA to 365 create a MCMemberRecord corresponding to the MGID. The SA will return 366 all the link attributes for the local node to use. The node MUST use 367 these attributes in all future multicast operations to the local 368 IPoIB link. The broadcast group for IPv4 will serve to provide a 369 broadcast service for protocol like ARP to use. 371 In addition to the all-node multicast/broadcast group, an all-router 372 multicast group SHOULD be created at link configuration time if an IP 373 router will be attached to the link. This is to facilitate IP 374 multicast operations described later. A MCGroupRecord for the all- 375 router MGID must be created in every IB subnet that the IPoIB link 376 encompasses. The format of the all-router MGID will be covered in 377 next section. 379 8. Mapping for other Multicast Groups 381 The support of general IP multicast [IPMULT] over IB is similar to 382 the case of the special all-node multicast/broadcast group discussed 383 above. An algorithmic mapping is used so that given an IP multicast 384 address, individual host can compute the corresponding IB multicast 385 address (MGID) all by itself without having to consult an external 386 entity. This also removes the need for an externally maintained IP to 387 IB multicast mapping table. 389 The IPoIB multicast mapping is defined as follows. The same mapping 390 function is used for both IPv4 and IPv6 except the IPoIB signature 391 field. 393 | 8 | 4 | 4 | 16 bits | 16 bits | 80 bits | 394 +------ -+----+----+-----------------+---------+--------------------+ 395 |11111111|0001|scop||< P_Key >| group ID | 396 +--------+----+----+-----------------+---------+--------------------+ 398 Since a MGID allocated for transporting IP multicast datagrams is 399 considered only a transient link-layer multicast address, all IB 400 MGIDs allocated for IPoIB purpose SHOULD have T = 1. The scope bits 401 SHALL be the same as that of the all-node MGID for the same IPoIB 402 link. 404 An IP multicast address is used together with a given IPoIB link 405 P_Key to form the MGID of the IB multicast group. For IPv6 the lower 406 80-bit of the group ID is used directly in the lower 80-bit of the 407 MGID. For IPv4, the group ID is only 28-bit long and the rest of the 408 80 bits are filled with 0. 410 The rest of the bits are the same as those of the all-node MGID. 411 E.g. on an IPoIB link that is fully contained within a single IB 412 subnet with a P_Key of 8, the MGIDs for the all-router multicast 413 group with group ID 2 [AARCH, IGMP2] are: 415 FF12:401B:8:0:0:0:0:2 417 or 419 FF12:401B:8::2 421 for IPv4 in a compressed format, and 423 FF12:601B:8:0:0:0:0:2 425 or 427 FF12:601B:8::2 429 for IPv6 in a compressed format. 431 A special case exists for the IPv4 limited broadcast address 432 "255.255.255.255" [HOSTS]. The address SHALL be mapped to the 433 broadcast MGID for IPv4 networks as described in section 7 above. 434 Also the IPv6 all-node multicast address "FF0X::1" [AARCH] will be 435 mapped to the the special all-node MGID for IPv6 networks. 437 When a node wishes to join an IP multicast group on a local link, it 438 first needs to construct the corresponding MGID, using the rule 439 described above. Note that it must remember the scope bits from the 440 all-node MGID, and use the same scope in all later MGIDs it 441 constructs. 443 The local node then checks with SA to see if a MCGroupRecord 444 corresponding to the MGID already exists. If not, one must be created 445 first. The MCGroupRecord MUST be created with the IPoIB link MTU. For 446 the rest of the attributes, it is recommended that it uses the same 447 values from the all-node multicast/broadcast group corresponding to 448 the link. 450 Note that for an IPoIB link that spans more than one IB subnet 451 connected by IB routers, adequate multicast forwarding support at the 452 IB level is required for multicast packets to be forwarded properly 453 to members in remote IB subnets. The specific mechanism for this will 454 be covered in [IBTA], and is out of scope of this document. 456 Once the IB multicast group is identified, the node must join the 457 group, unless it is a member already, by calling the SA to create a 458 MCMemberRecord corresponding to the MGID. The join call enables SM 459 to program local IB switches and routers with the new multicast 460 information. Specifically it causes an IB switch to add the LID of 461 the caller to its forwarding table entry corresponding to the MLID 462 allocated for the group. It also causes an IB router to attach 463 itself to the IB multicast tree corresponding to the MGID. 465 When a node leaves an IP multicast group, it SHOULD delete the 466 MCMemberRecord from the SA. This allows the SA to free up related 467 resources. SM should delete MCGroupRecords that are no longer in use, 468 and free up the MLIDs allocated for them. The specific algorithm is 469 implementation-dependent, and therefore is out of scope of this 470 document. 472 In order to send a packet destined for an IP multicast address, a 473 node must first check if a MCGroupRecord for the corresponding MGID 474 of the outbound link exists or not. If one already exists, the MLID 475 allocated by the SM for the MCGroupRecord is used as the DLID for the 476 packet. Otherwise, it means no member exists on the local link. The 477 packet should be forwarded to the all-router multicast group 478 described before. If one doesn't already exist, it implies no router 479 presence on the local subnet. The packet can then be silently 480 dropped. 482 Note that the local node MUST be notified when an IB multicast group 483 corresponding to the MGID ever comes into existence later. This 484 signifies that an interested party just showed up on the local link 485 and therefore must be copied. 487 9. Support for IP Multicast Routing 489 IP multicast routing requires a router to receive a copy of every 490 link multicast packet on a locally connected link [IPMULT, IP6MLD]. 491 For Ethernet this is usually done by turning on promiscuous multicast 492 mode on a locally connected Ethernet interface. 494 Unfortunately IBA does not support promiscuous multicast mode. 495 Therefore the IPoIB driver should forward a copy of every outbound 496 multicast datagram to the MGID corresponding to the all-router 497 multicast group. This is to ensure multicast packets be properly 498 forwarded to remote IP networks. 500 10. Security Considerations 502 All the operations for creating and configuring an IPoIB link 503 described in this document, including assigning P_Keys to CAs, 504 creating MCGroupRecords and MCMemberRecords in SA, creating and 505 attaching QPs to IB multicast groups,... etc are privileged 506 operations, and MUST be protected by the underlying operating system. 507 This is to prevent malicious, non- privileged software from hijacking 508 important resources and configurations. E.g. A bogus all-node IPoIB 509 multicast group may prevent a proper one from being created when the 510 network administrator tries to set up a link. 512 Controlled Q_Keys SHOULD be used in IB multicast groups in order to 513 prevent non-privileged software from fabricating IP datagrams to 514 send, as mentioned in section 6.2. 516 11. Acknowledgments 518 The authors would like to thank Bruce Beukema, David Brean, Dan 519 Cassiday, Thomas Narten, Erik Nordmark, Greg Pfister, Renato Recio, 520 David L. Stevens, and Madhu Talluri for their suggestions and many 521 clarifications on the IBA specification. 523 12. References 525 [AARCH] Hinden, R. and S. Deering "IP Version 6 Addressing 526 Architecture", RFC 2373, July 1998. 528 [DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 529 Discovery for IP Version 6 (IPv6)", RFC 2461, December 530 1998. 532 [HOSTS] Braden R., "Requirements for Internet Hosts -- 533 Communication Layers", RFC 1122, October 1989 535 [IBTA] InfiniBand Architecture Specification, Release 1.0.a by 536 InfiniBand Trade Association at www.infinibandta.org 538 [IGMP2] Fenner W., "Internet Group Management Protocol, Version 2", 539 RFC 2236, November 1997. 541 [IPMULT] Deering S., "Host Extensions for IP Multicasting", RFC 542 1112, August 1989. 544 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 545 (IPv6) Specification", RFC 2460, December 1998. 547 [IP6MLD] Deering S., Fenner W., Haberman B., "Multicast Listener 548 Discovery (MLD) for IPv6", RFC 2710, October 1999. 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, March 1997. 553 13. Author's Address 555 H.K. Jerry Chu 556 901 San Antonio Road, UMPK17-201 557 Palo Alto, CA 94303-4900 558 USA 560 Phone: +1 650 786-5146 561 EMail: jerry.chu@sun.com 563 Vivek Kashyap 564 IBM 565 15450, SW Koll Parkway 566 Beaverton, OR 97006 568 Phone: 503 578 3422 569 EMail: vivk@us.ibm.com 571 14. Full Copyright Statement 572 Copyright (C) The Internet Society (2001>. All Rights Reserved. 574 This document and translations of it may be copied and furnished to 575 others, and derivative works that comment on or otherwise explain it 576 or assist in its implementation may be prepared, copied, published 577 and distributed, in whole or in part, without restriction of any 578 kind, provided that the above copyright notice and this paragraph are 579 included on all such copies and derivative works. However, this 580 document itself may not be modified in any way, such as by removing 581 the copyright notice or references to the Internet Society or other 582 Internet organizations, except as needed for the purpose of 583 developing Internet standards in which case the procedures for 584 copyrights defined in the Internet Standards process must be 585 followed, or as required to translate it into languages other than 586 English. 588 The limited permissions granted above are perpetual and will not be 589 revoked by the Internet Society or its successors or assigns. 591 This document and the information contained herein is provided on an 592 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 593 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 594 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 595 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 596 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.