idnits 2.17.1 draft-ietf-ipoib-ip-over-infiniband-04.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 14 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 15 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 8 instances of too long lines in the document, the longest one being 5 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.) -- 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) == Missing Reference: 'IBARCH' is mentioned on line 445, but not defined == Unused Reference: 'RFC2375' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'RFC1700' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC3041' is defined on line 599, 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 (~~), 10 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: October, 2003 H.K.Jerry Chu 5 Sun Microsystems 7 April, 2003 9 IP encapsulation and address resolution over InfiniBand networks 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet 17 Engineering Task Force (IETF), its areas, and its working 18 groups. Note that other groups may also distribute working 19 documents as Internet- Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use 24 Internet-Drafts as Reference material or to cite them other 25 than as ``work in progress''. 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed 31 at http://www.ietf.org/shadow.html 33 This memo provides information for the Internet community. 34 This memo does not specify an Internet standard of any kind. 35 Distribution of this memo is unlimited. 37 Copyright Notice 39 Copyright (C) The Internet Society (2001). All Rights Reserved. 41 Abstract 43 This document specifies the frame format for transmission of 44 IP and ARP packets over InfiniBand networks. Unless explicitly 45 specified, the term 'IP' refers to both IPv4 and IPv6. The 46 term 'ARP' refers to all the ARP protocols/op-codes such as 47 ARP/RARP. This document also describes the method of forming 48 IPv6 link-local addresses, and the content of the 49 source/target link layer address option used in Neighbor 50 solicitation and advertisement, router advertisement, router 51 redirect and router solicitation on IPv6 over InfiniBand. 53 Table of Contents 55 1.0 Introduction 56 2.0 InfiniBand Datalink 57 2.1 IP Support on IPoIB Link 58 3.0 Frame Format 59 4.0 Maximum Transmission Unit 60 5.0 IPv6 Stateless Autoconfiguration 61 5.1 IPv6 Link Local Address 62 6.0 Address Mapping - Unicast 63 6.1 Link-Information 64 6.1.1 Link Layer Address/Hardware Address 65 6.1.2 Auxiliary Link Information 66 6.2 Address Resolution in IPv4 Subnets 67 6.3 Address Resolution in IPv6 Subnets 68 6.4 Cautionary Note on QPN Caching 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. The transmission of IP over other modes of 93 IB is beyond the scope of this document. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 96 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described 98 in RFC 2119. 100 2.0 InfiniBand Datalink 102 The document [IPoIB_MCAST] defines the IPoIB link, its setup, 103 and IP multicast over InfiniBand in detail. The following 104 discussion gives a short overview. 106 An InfiniBand(IB) subnet is formed by a network of IB nodes 107 interconnected either directly or via IB switches. IB subnets 108 may be connected using IB routers to form a fabric made of 109 multiple IB subnets. Multiple IP subnets may be overlaid over 110 this IB cloud. The boundary of this IP subnet is arbitrary and 111 not associated with a physical demarcation. The IPoIB nodes 112 that are members of this subnet are interconnected by an 113 abstract 'link'. The link is defined by its members and common 114 characteristics such as the P_Key, link MTU and Q_Key that are 115 defined per 'link'. 117 IPv4 defines a limited-broadcast address over the link. All 118 IPv4 hosts that are members of the IPv4 subnet are members of 119 this address. IPv6 defines a multicast address referred to as 120 the all-IP hosts address. IPoIB defines a mapping from these 121 (and other IPv4/v6 multicast addresses) to IB multicast GIDs 122 [IPoIB_MCAST]. The multicast GID derived from the IPv4 123 limited-broadcast address and the multicast GID derived from 124 the IPv6 all-nodes multicast address will collectively be 125 referred to as the broadcast-GID in this document. The 126 broadcast-GID is required to be setup for an IPoIB subnet to 127 be formed. 129 Every IPoIB interface MUST join the InfiniBand multicast group 130 defined by the broadcast-GID. This operation returns the MTU 131 and the Q_Key associated with the IPoIB link. Thus the IPoIB 132 subnet (and the link) is formed by the IPoIB nodes joining the 133 broadcast GID. 135 The P_Key is a configuration parameter that must be known 136 before the broadcast-GID can be formed[IPoIB_MCAST]. 138 2.1 IP Support on IPoIB Link 140 The unreliable datagram (UD) mode of communication is 141 supported by all IB elements be they IB routers, Host Channel 142 Adapters(HCAs) or Target Channel Adapters(TCAs). In addition 143 to being the only universal transmission method it supports 144 multicasting, partitioning and a 32-bit CRC [IB_ARCH]. IB does 145 not require that all IB components support multicasting. 146 Therefore, IB subnets with no multicast support are always 147 possible. However, IPoIB architecture requires the 148 participating components to support multicast. 150 All IPoIB implementations MUST support IP over the unreliable 151 datagram (UD) transport mode of IBA. 153 3.0 Frame Format 155 All IP and ARP datagrams transported over InfiniBand are 156 prefixed by a 4-octet encapsulation header as illustrated 157 below. 159 0 1 2 3 160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | | 163 | Type | Reserved | 164 | | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 1 169 The type field SHALL indicate the encapsulated protocol as per 170 the following table. 172 +----------+-------------+ 173 | Type | Protocol | 174 |------------------------| 175 | 0x800 | IPv4 | 176 |------------------------| 177 | 0x806 | ARP | 178 |------------------------| 179 | 0x8035 | RARP | 180 |------------------------| 181 | 0x86DD | IPv6 | 182 +------------------------+ 184 Table 1 186 These values are taken from the 'ETHER TYPE' numbers assigned 187 by [IANA]. Other network protocols, identified by different 188 values of 'ETHER TYPE', may use the encapsulation format 189 defined herein but such use is outside of the scope of this 190 document. 192 |<------ IB Frame headers -------->|<- Payload ->|<- IB trailers ->| 193 +-------+------+---------+---------+-------------+---------+-------+ 194 |Local | |Base |Datagram | 4-octet | | | 195 |Routing| GRH* |Transport|Extended | header |Invariant|Variant| 196 |Header |Header|Header |Transport| + | CRC | CRC | 197 | | | |Header | IP/ARP | | | 198 +-------+------+---------+---------+-------------+---------+-------+ 200 Figure 2 202 Figure 2 depicts the IB frame encapsulating an IP/ARP 203 datagram. The IB frame headers are described in detail in the 204 InfiniBand Architecture specificaton [IBARCH]. The InfiniBand 205 specification requires the use of Global Routing Header (GRH) 206 [IPoIB_ARCH] when multicasting or when an InfiniBand packet 207 traverses from one IB subnet to another through an IB router. 208 Its use is optional when used for unicast transmission between 209 nodes within an IB subnet. The IPoIB implementation MUST be 210 able to handle packets received with or without the use of 211 GRH. 213 4.0 Maximum Transmission Unit 215 IB MTU: 216 The IB components i.e. IB links, switches, CAs, and IB 217 routers, may support maximum payloads of : 256, 512, 218 1024, 2048 or 4096 bytes. The maximum IB payload 219 supported by the IB components in any IB path is the 220 IB MTU for the path. 222 IPoIB-Link MTU: 223 An IPoIB link is formed by the IPoIB nodes joining the 224 broadcast-GID [IPoIB_MCAST]. The IPoIB-link MTU is the 225 MTU value associated with the broadcast-GID. The 226 IPoIB-link MTU can be set to any value upto the 227 smallest IB MTU supported by the IB components 228 comprising the IPoIB link. 230 In order to reduce problems with fragmentation and path-MTU 231 discovery, this document requires that all IPoIB 232 implementations support an MTU of 2044 octets i.e. a 2048 233 octet IPoIB-link MTU minus the 4 octet encapsulation overhead. 234 Larger and smaller MTUs MAY be supported, but the default 235 configuration must be support an MTU of 2044 octets. 237 In IPv6 subnets the MTU may be reduced by a Router 238 Advertisement [RFC2461] containing an MTU option which 239 specifies a smaller MTU, or by manual configuration of each 240 node. If a Router Advertisement received on an IPoIB interface 241 has an MTU option specifying an MTU larger than the link MTU 242 or larger than a manually configured value, that MTU option 243 may be logged to system management but must be otherwise 244 ignored. 246 Similarly, the IPv4 MTU may also be reduced by manual 247 configuration of each node. 249 For purposes of this document, information received from DHCP 250 is considered "manually configured". 252 5.0 IPv6 Stateless Autoconfiguration 254 IB architecture associates an EUI-64 identifier termed the 255 GUID (Globally Unique Identifier) [IPoIB_ARCH, IB_ARCH] with 256 each port. The LID (16 bits) is unique within an IB subnet 257 only. 259 The interface identifier may be chosen from: 261 1) The EUI-64 compliant Globally unique 262 identifier(GUID) assigned by the manufacturer. 264 2) If the IPoIB subnet is fully contained within an IB 265 subnet any of the unique 16-bit LIDs of the port 266 associated with the IPoIB interface. 268 The LID values of a port may change after a 269 reboot/power-cycle of the IB node. Therefore, if a 270 persistent value is desired, it would be prudent to 271 not use the LID to form the interface identifier. 273 On the other hand, the LID provides an identifier 274 that can be used to create a more anonymous IPv6 275 address since the LID is not globally unique and is 276 subject to change over time. 278 It is RECOMMENDED that the link-local address be constructed 279 from the port's EUI-64 identifier as per the rules specified 280 in [RFC2373]. 282 5.1 IPv6 Link Local Address 284 The IPv6 link local address for an IPoIB interface is formed 285 as described in [RFC2373] using the Interface Identifier 286 described in the previous section. 288 6.0 Address Mapping - Unicast 290 Address resolution in IPv4 subnets is accomplished through 291 Address Resolution protocol (ARP)[RFC826]. It is accomplished 292 in IPv6 subnets using the Neighbor discovery 293 protocol[RFC2461]. 295 6.1 Link Information 297 An InfiniBand packet over the UD mode includes multiple 298 headers such as the LRH(local route header), GRH(global route 299 header), BTH(base transport header), DETH(datagram extended 300 header) as depicted in Figure 2 and specified in the 301 InfiniBand architecture[IB_ARCH]. All these headers comprise 302 the link-layer in an IPoIB link. 304 The parameters needed in these IBA headers constitute the 305 link-layer information that needs to be determined before an 306 IP packet may be transmitted across the IPoIB link. 308 The parameters that need to be determined are: 310 a) LID (local identifier) 312 The LID is always needed. A packet always includes the 313 LRH that is targeted at the remote node's LID, or an 314 IB router's LID to get to the remote node in another 315 IB subnet. 317 b) GID (global identifier) 319 The GID is not needed when exchanging information 320 within an IB subnet though it may be included in any 321 packet. It is an absolute necessity when transmitting 322 across multiple IB subnets since the IB routers use the GID 323 to correctly forward the packets. The source and 324 destination GIDs are fields included in the GRH. 326 The GID, if formed using the GUID, can be used to 327 unambiguously identify an endpoint. 329 c) QPN (queue pair number) 331 Every unicast UD communication is always directed to a 332 particular queue pair(QP) at the peer. 334 d) Q_Key 336 A Q_Key is associated with each unreliable datagram 337 QPN. The received packets must contain a Q_Key that 338 matches the QP's Q_Key to be accepted. 340 e) P_Key 342 A successful communication between two IB nodes using 343 UD mode can occur only if the two nodes have 344 compatible P_Keys. This is referred to as being in the 345 same partition[IB_ARCH]. P_Keys are checked at the 346 receiving channel adapter and may be optionally 347 checked at intermediate switches/IB routers. If the 348 P_Key in the packet does not match the expected P_Key 349 the packet is dropped. 351 f) SL (service level) 353 Every IBA packet contains an SL value. A path in IBA 354 is defined by the three-tuple (source LID, destination 355 LID, SL). The SL in turns is mapped to a virtual 356 lane(VL) at every CA, switch that sends/forwards the 357 packet [IPoIB_ARCH]. Multiple SLs may be used between 358 two endpoints to provide for load-balancing, SLs may 359 be used for providing a QoS infrastructure, or may be 360 used to avoid deadlocks in the IBA fabric. 362 Another auxiliary piece of information, not included in 363 the IBA headers, is : 365 g) Path rate 367 The InfiniBand architecture defines multiple link 368 speeds. A higher speed transmitter can swamp the 369 switches and the CAs. To avoid such congestion every 370 source transmitting at greater than 1x speeds is 371 required to determine the 'path rate' before the data 372 may be transmitted [IB_ARCH]. 374 6.1.1 Link Layer Address/Hardware Address 376 Though the list of information required for a successful 377 transmittal of an IPoIB packet is large not all the 378 information need be determined during the IP address 379 resolution process. 381 The IPoIB link-layer address used in the source/target 382 link-layer address option in IPv6 and the 'hardware address' 383 in IPv4/ARP has the same format. 385 The format is as described below: 387 0 1 2 3 388 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Reserved | Queue Pair Number | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 + + 394 | | 395 + GID + 396 | | 397 + + 398 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Figure 3 403 a) Reserved Flags 405 These 8 bits are reserved for future use. These bits 406 MUST be set to zero on send and ignored on receive 407 unless specified differently in a future document. 409 b) Queue Pair Number (QPN) 411 Every unicast communication in IB architecture is 412 directed to a specific queue pair(QP)[IB_ARCH]. This 413 QP number is included in the link description. All IP 414 communication to the relevant IPoIB interface MUST be 415 directed to this QPN. In the case of IPv4 subnets the 416 address resolution protocol(ARP) reply packets are 417 also directed to the same QPN. 419 The choice of the QPN value for IP/ARP communication 420 is up to the receiving implementation. 422 c) Global Identifier (GID) 424 This is one of the Global Identifiers(GIDs)[IB_ARCH] 425 of the port associated with the IPoIB interface. IB 426 associates multiple GIDs with a port. It is 427 RECOMMENDED that the 'GID at index 0' be included in 428 the link-layer/hardware address [IBARCH]. The GID at 429 index 0 is formed using the IB port's manufacturer 430 assigned EUI-64 identifier. 432 6.1.2 Auxiliary Link Information 434 The rest of the parameters are determined as follows: 436 a) Local Identifier(LID) 438 The method of determining the peer's LID is not 439 defined in this document. It is up to the 440 implementation to use any of the IBA approved methods 441 to determine the destination LID. One such method is 442 to use the GID determined during the address 443 resolution, to retrieve the associated LID from the IB 444 routing infrastructure or the Subnet 445 Administrator(SA)[IBARCH]. 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, Neighbor 516 Solicitation and Neighbor 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 6.1.1 530 and depicted in Figure 3. 532 6.4 Cautionary Note on QPN Caching 534 The link-address for IPoIB includes the QPN which might not be 535 constant across reboots or even across network interface 536 resets. Cached QPN entries, such as in static ARP entries or 537 in RARP servers will only work if the implementation(s) using 538 these options ensure that the QPN associated with an interface 539 is invariant across reboots/network resets. 541 7.0 IANA Considerations 543 To support ARP over InfiniBand a value for the Address 544 Resolution Parameter 'Number Hardware Type (hrd)' is required. 545 IANA has assigned the number '32' to indicate 546 InfiniBand[IANA_ARP]. 548 8.0 Security Considerations 550 This document specifies IP transmission over a multicast 551 network. Any network of this kind is vulnerable to a sender 552 claiming another's identity and forge traffic or eavesdrop. It 553 is the responsibility of the higher layers or applications to 554 implement suitable counter-measures if this is a problem. 556 Successful transmission of IP packets depends on the correct 557 setup of the IPoIB link [IPOIB_MCAST], creation of the 558 broadcast GID, creation of the QP and its attachment to the 559 broadcast-GID, and the correct determination of various link 560 parameters such as the LID, service level, path rate etc. 561 These operations, many of which involve interactions with the SM/SA, 562 MUST be protected by the underlying operating system. This is 563 to prevent malicious, non- privileged software from hijacking 564 important resources and configurations. 566 Controlled Q_Keys SHOULD be used in all transmissions. This is 567 to prevent non-privileged software from fabricating IP 568 datagrams. 570 9.0 Acknowledgements 572 The authors would like to thank Bruce Beukema, David Brean, 573 Dan Cassiday, Yaron Haviv, Thomas Narten, Erik Nordmark, Greg 574 Pfister, Jim Pinkerton, Renato Recio, Kevin Reilly, Madhu 575 Talluri and Satya Sharma for their suggestions and many 576 clarifications on the IBA specification. 578 10.0 References 580 [IB_ARCH] InfiniBand Architecture Specification, Volume 1.0a 581 www.infinibandta.org 583 [IPoIB_ARCH] draft-ietf-ipoib-architecture-02.txt 585 [IPoIB_MCAST] draft-ietf-ipoib-link-multicast-03.txt 587 [RFC2373] IP Version 6 Addressing Architecture 589 [RFC2375] IPv6 Multicast Address Assignments 591 [RFC826] An Ethernet Address Resolution Protocol 593 [RFC1700] Assigned Numbers. 595 [RFC2434] Guidelines for Writing an IANA Considerations Section in RFCs 597 [RFC2461] Neighbor Discovery for IP version 6 (IPv6) 599 [RFC3041] Extensions to IPv6 Address Autoconfiguration 601 [IANA] Internet assigned numbers authority, www.iana.org 603 [IANA_ARP] www.iana.org/assignments/arp-parameters 604 11.0 Authors' Address 606 Vivek Kashyap 608 15450, SW Koll Parkway 609 Beaverton, OR 97006 610 USA 612 Phone: +1 503 578 3422 613 Email: vivk@us.ibm.com 615 H.K. Jerry Chu 617 17 Network Circle, UMPK17-201 618 Menlo Park, CA 94025 619 USA 621 Phone: +1 650 786-5146 622 Email: jerry.chu@sun.com 624 Full Copyright Statement 626 Copyright (C) The Internet Society (2001). All Rights Reserved. 628 This document and translations of it may be copied and 629 furnished to others, and derivative works that comment on or 630 otherwise explain it or assist in its implementation may be 631 prepared, copied, published and distributed, in whole or in 632 part, without restriction of any kind, provided that the above 633 copyright notice and this paragraph are included on all such 634 copies and derivative works. However, this document itself may 635 not be modified in any way, such as by removing the copyright 636 notice or references to the Internet Society or other Internet 637 organizations, except as needed for the purpose of developing 638 Internet standards in which case the procedures for copyrights 639 defined in the Internet Standards process must be followed, or 640 as required to translate it into languages other than 641 English. 643 The limited permissions granted above are perpetual and will 644 not be revoked by the Internet Society or its successors or 645 assigns. 647 This document and the information contained herein is provided 648 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 649 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 650 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 651 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 652 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 653 PARTICULAR PURPOSE.