idnits 2.17.1 draft-ietf-nfsv4-rpc-netid-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC1833, but the abstract doesn't seem to directly say this. It does mention RFC1833 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1833, updated by this document, for RFC5378 checks: 1994-11-30) -- 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 (January 30, 2009) is 5563 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) -- Obsolete informational reference (is this intentional?): RFC 1831 (ref. '4') (Obsoleted by RFC 5531) -- Obsolete informational reference (is this intentional?): RFC 3530 (ref. '5') (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '7') (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. '8') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '12') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '13') (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 M. Eisler 3 Internet-Draft NetApp 4 Updates: 1833 (if approved) January 30, 2009 5 Intended status: Standards Track 6 Expires: August 3, 2009 8 IANA Considerations for RPC Net Identifiers and Universal Address 9 Formats 10 draft-ietf-nfsv4-rpc-netid-06.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other 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 at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 3, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This Internet-Draft lists IANA Considerations for RPC Network 50 Identifiers (netids) and RPC Universal Network Addresses (uaddrs). 51 This Internet-Draft updates, but does not replace, RFC1833. 53 Requirements Language 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [1]. 59 Table of Contents 61 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 62 2. Considerations for the Netid of the SCTP Protocol . . . . . . 3 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 65 4.1. IANA Considerations for Netids . . . . . . . . . . . . . . 3 66 4.1.1. Initial Registry . . . . . . . . . . . . . . . . . . . 6 67 4.1.2. Updating Registrations . . . . . . . . . . . . . . . . 8 68 4.2. IANA Considerations for Uaddr Formats . . . . . . . . . . 8 69 4.2.1. Initial Registry . . . . . . . . . . . . . . . . . . . 9 70 4.2.2. Updating Registrations . . . . . . . . . . . . . . . . 9 71 4.2.3. Uaddr Formats . . . . . . . . . . . . . . . . . . . . 10 72 4.3. Cross Referencing Between the Netid and Format Registry . 11 73 4.4. Port Assignment for NFS over SCTP . . . . . . . . . . . . 11 74 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 5.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 78 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 12 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction and Motivation 83 The concepts of an RPC (defined in RFC1831 [4]) Network Identifier 84 (netid) and an RPC Universal Address (uaddr) were introduced in 85 RFC1833 [2] for distinguishing network addresses of multiple 86 protocols and representing those addresses in a canonical form. 87 RFC1833 states that a netid ``is defined by a system administrator 88 based on local conventions, and cannot be depended on to have the 89 same value on every system.'' (The netid is contained in the field 90 r_netid of the data type rpcb_entry, and the uaddr is contained in 91 the field r_addr of the same data type, where rpcb_entry is defined 92 in RFC1833.) Since the publication of RFC1833, it has been found 93 that protocols like NFSv4.0 [5] and RPC/RDMA [6] depend on consistent 94 values of netids and representations of uaddrs. Current practices 95 tend to ensure this consistency. Thus, this document identifies the 96 considerations for IANA to establish registries of netids and uaddr 97 formats for RPC and specifies the initial content of the two 98 registries. 100 2. Considerations for the Netid of the SCTP Protocol 102 The SCTP protocol (described in RFC4960 [7]) is a connection-oriented 103 protocol that supports both byte-streamed and record-oriented data 104 transfer. When the "sctp" and "sctp6" netids are used, the ONC RPC 105 Record Marking standard (see Section 10 of RFC1831 [4]) are not used; 106 instead, SCTP's native record-oriented data transfer is used. 108 3. Security Considerations 110 Since this document is only concerned with the IANA management of the 111 Network Identifier (netid) and Universal Network Addresses (uaddrs) 112 format registry, it raises no new security issues. 114 4. IANA Considerations 116 This section uses terms that are defined in RFC5226 [8]. 118 4.1. IANA Considerations for Netids 120 IANA will create a registry called "ONC RPC Netids". The remainder 121 of this section describes the registry. 123 All assignments to the ONC RPC Netids registry are made on one of two 124 bases: 126 o A First Come First Served basis subregistry per section 4.1 of 127 RFC5226. 129 o A Standards Action basis subregistry per section 4.1 of RFC5226. 131 The XDR encoding allows netids to be up to 2^32 - 1 octets in length, 132 but the registry will only allow a much shorter length. Assignments 133 made on a Standards Action basis should be assigned netids one to 134 eight octets long. Assignments made on a First Come First Served 135 basis should be assigned netids nine to 128 octets long. Some 136 exceptions are listed in Table 2. 138 Some portion of the netid name space is Reserved: 140 o All netids, regardless of length, that start with the prefixes 141 "STDS" or "FCFS" are Reserved, in order to extend the name space 142 of either Standards Action or First Come First Served bases. 144 o To give IESG the flexibility in the future to permit Private and 145 Experimental Uses, all netids with the prefixes "PRIV" or "EXPE" 146 are Reserved. 148 o To prevent confusion with the control protocol by the same name 149 [9], netids with the prefix "ICMP" are Reserved. 151 o Since netids are not constructed in an explicit hierarchical 152 manner, this document does not provide for Hierarchical Allocation 153 of netids. Nonetheless, all netids containing the octet "." are 154 Reserved for future possible provision of Hierarchical Allocation. 156 o The zero length netid is Reserved. 158 A recommended convention for netids corresponding to transports that 159 work over the IPv6 protocol is to have "6" as the last character in 160 the netid's name. 162 There are two subregistries of netids, one for Standards Action 163 assignments, and one for First Come First Serve assignments. Each 164 registry of netids is a list of assignments, each containing five 165 fields for each assignment. 167 1. A US-ASCII string name that is the actual netid. The netid 168 should be one to eight octets long for the Standards Action 169 subregistry, and should be nine to 128 octets long for the First 170 Come First Served subregistry. The netid MUST NOT conflict with 171 any other registered netid. Despite the fact that netids are 172 case sensitive, the netid, when mapped to all upper case MUST NOT 173 conflict with the value of any other registered netid after the 174 registered netid is mapped to upper case. In addition, when 175 mapped to upper case, the prefix of the netid MUST NOT be equal 176 to a Reserved prefix. 178 2. A constant name that can be used for software programs that wish 179 to use the transport protocol associated with protocol. The name 180 of the constant typically has the prefix: "NC_", and a suffix 181 equal to the upper case version of the netid. This constant name 182 should be a constant that is valid in the 'C' programming 183 language. This constant name MUST NOT conflict with any other 184 netid constant name. Constant names with the prefix "NC_STDS", 185 "NC_FCFS", "NC_PRIV", "NC_EXPE", and "NC_ICMP" are Reserved. 186 Constant names with a prefix of "NC_" and a total length of 11 187 characters or less should be for assignments made on the 188 Standards Action basis. The constant "NC_" is Reserved. The 189 constant name can be one to 131 octets long. 191 Given the typical derivation of the constant name from the netid, 192 the registration of the constant might be considered redundant. 193 This is not always true. For example, a netid might use a 194 character than is not valid in the programming language. The 195 first entry of Table 1 provides such an example. 197 3. A description and/or a reference to a description of the how the 198 netid will be used. For assignments made on a First Come First 199 Served basis the description should include, if applicable, a 200 reference to the transport and network protocols corresponding to 201 the netid. For assignments made on a Standards Action basis, the 202 description field must include the RFC numbers of the protocol 203 associated with the netid, including if applicable, RFC numbers 204 of the transport and network protocols. 206 4. A point of contact of the registrant. For assignments made on a 207 First Come First Served basis, 209 * the point of contact should include an email address. 211 * subject to authorization by a Designated Expert, the point of 212 contact may be omitted for extraordinary situations, such as 213 the registration of a commonly used netid where the owner is 214 unknown. 216 For assignments made on a Standards Action basis the point of 217 contact is always determined by IESG. 219 5. A numerical value, used to cross reference the netid assignment 220 with an assignment in the uaddr format registry (see 221 Section 4.2). If the registrant is registering a netid that 222 cross references an existing assignment in the uaddr format 223 registry, then the registrant provides the actual value of the 224 cross reference along with the date the registrant retrieved the 225 cross reference value from the uaddr format registry. If the 226 registrant is registering both a new netid and new uaddr format, 227 then the registrant provides a value of TBD1 in the netid 228 request, and uses TBD1 in the the uaddr format request. IANA 229 will then substitute TBD1 for cross reference number IANA 230 allocates. Note that if a document requests multiple netid and 231 uaddr assignments, each additional uaddr format cross reference 232 will be identified as TBD2, TBD3, ..., etc. 234 4.1.1. Initial Registry 236 The initial list of netids is broken into two subregistries: those 237 assigned on a First Come First Serve basis in Table 1 and those 238 assigned on a Standards Action basis in Table 2. These lists will 239 change when IANA registers additional netids as needed, and the 240 authoritative list of registered netids will always live with IANA. 242 +-------------+--------------+---------------------------+-----+----+ 243 | Netid | Constant | Description and/or | PoC | CR | 244 | | Name | Reference | | | 245 +-------------+--------------+---------------------------+-----+----+ 246 | "-" | NC_NOPROTO | RFC1833 [2], | | 1 | 247 | | | Section 4.2.3.2 of | | | 248 | | | RFCTBD2 | | | 249 | "ticlts" | NC_TICLTS | The loop back | | 0 | 250 | | | connectionless transport | | | 251 | | | used in System V Release | | | 252 | | | 4 and other operating | | | 253 | | | systems. Although this | | | 254 | | | assignment is made on a | | | 255 | | | First Come First Served | | | 256 | | | basis and is fewer than | | | 257 | | | nine characters long, the | | | 258 | | | exception is authorized. | | | 259 | | | See [10]. | | | 260 | "ticots" | NC_TICOTS | The loop back | | 0 | 261 | | | connection-oriented | | | 262 | | | transport used in System | | | 263 | | | V Release 4 and other | | | 264 | | | operating systems. See | | | 265 | | | [10]. Although this | | | 266 | | | assignment is made on a | | | 267 | | | First Come First Served | | | 268 | | | basis and is fewer than | | | 269 | | | nine characters long, the | | | 270 | | | exception is authorized. | | | 271 | "ticotsord" | NC_TICOTSORD | The loop back | | 0 | 272 | | | connection-oriented with | | | 273 | | | orderly-release transport | | | 274 | | | used in System V Release | | | 275 | | | 4 and other operating | | | 276 | | | systems. See [10]. | | | 277 +-------------+--------------+---------------------------+-----+----+ 279 Table 1: Initial First Come First Serve Netid Assignments 281 PoC: Point of Contact. CR: Cross Reference to the Uaddr Format 282 Registry. 284 +---------+-----------+---------------------------------+------+----+ 285 | Netid | Constant | RFC(s) and Description (if | PoC | CR | 286 | | Name | needed) | | | 287 +---------+-----------+---------------------------------+------+----+ 288 | "rdma" | NC_RDMA | RFCTBD1 [6] RFC0791 [11] | IESG | 2 | 289 | "rdma6" | NC_RDMA6 | RFCTBD1 [6] RFC2460 [12] | IESG | 3 | 290 | "sctp" | NC_SCTP | RFC4960 [7] RFC0791 [11] | IESG | 2 | 291 | | | Section 2 of RFCTBD2 | | | 292 | "sctp6" | NC_SCTP6 | RFC4960 [7] RFC2460 [12] | IESG | 3 | 293 | | | Section 2 of RFCTBD2 | | | 294 | "tcp" | NC_TCP | RFC0793 [13] RFC0791 [11] | IESG | 2 | 295 | | | Section 10 of RFC1831 [4] | | | 296 | "tcp6" | NC_TCP6 | RFC0793 [13] RFC2460 [12] | IESG | 3 | 297 | | | Section 10 of RFC1831 [4] | | | 298 | "udp" | NC_UDP | RFC0768 [14] RFC0791 [11] | IESG | 2 | 299 | "udp6" | NC_UDP6 | RFC0768 [14] RFC2460 [12] | IESG | 3 | 300 +---------+-----------+---------------------------------+------+----+ 302 Table 2: Initial Standards Action Netid Assignments 304 4.1.2. Updating Registrations 306 Per section 5.2 of RFC5226 the registrant is always permitted to 307 update a registration made on a First Come First Served basis 308 "subject to the same constraints and review as with new 309 registrations." IESG or a Designated Expert is permitted to update 310 any registration made on a First Come First Served basis, which 311 normally is done when the PoC cannot be reached in order to make 312 necessary updates. Examples where an update would be needed include, 313 but are not limited to: the email address or other contact 314 information becomes invalid; the reference to the corresponding 315 protocol becomes obsolete or unavailable; and RFC1833 is updated or 316 replaced in such a way that the scope of netids changes, requiring 317 additional fields in the assignment. 319 Only IESG, on the advice of a Designated Expert, can update a 320 registration made on a Standards Action basis. 322 4.2. IANA Considerations for Uaddr Formats 324 IANA will create a registry called "ONC RPC Uaddr Format Registry" 325 (called the "format registry" for the remainder of this document). 326 The remainder of this section describes the registry. 328 All assignments to the format registry are made on one of two bases: 330 o First Come First Served basis per section 4.1 of RFC5226. 332 o Standards Action per section 4.1 of RFC5226. 334 The registry of formats is a list of assignments, each containing 335 four fields for each assignment. 337 1. The basis for the assignment, which can be either FCFS for First 338 Come First Served assignments, or STDS for Standards Action 339 assignments. 341 2. A description and/or reference to a description of the actual 342 uaddr format. Assignments made on a Standards Action basis 343 always have a reference to an RFC. 345 3. For assignments made on a First Come First Served basis, a point 346 of contact, including an email address. Subject to authorization 347 by a Designated Expert, the point of contact may be omitted for 348 extraordinary situations, such as the registration of a commonly 349 used format where the owner is unknown. For assignments made on 350 a Standards Action basis, the point of contact is always 351 determined by IESG. 353 4. A numerical value, used to cross reference the format assignment 354 with an assignment in the netid registry. The registrant 355 provides a value of TBD1 for the cross reference field when 356 requesting an assignment. IANA will assign TBD1 to a real value. 357 Note that if a document requests multiple uaddr assignments, each 358 additional uaddr format cross reference will be identified as 359 TBD2, TBD3, ..., etc. 361 All requests for assignments to the format registry on a Standards 362 Action basis are only for Standards Track RFCs approved by the IESG. 364 4.2.1. Initial Registry 366 The initial list of formats is in Table 3. This lists will change 367 when IANA registers additional formats as needed, and the 368 authoritative list of registered formats will always live with IANA. 370 +-------+-----------------------------------------------+------+----+ 371 | Basis | Description and/or Reference | PoC | CR | 372 +-------+-----------------------------------------------+------+----+ 373 | FCFS | System V Release 4 loopback transport uaddr | | 0 | 374 | | format. Section 4.2.3.1 of RFCTBD2 | | | 375 | FCFS | Uaddr format for NC_NOPROTO. Section 4.2.3.2 | | 1 | 376 | | of RFCTBD2 | | | 377 | STDS | Uaddr format for IPv4 transports. | IESG | 2 | 378 | | Section 4.2.3.3 of RFCTBD2 | | | 379 | STDS | Uaddr format for IPv6 transports. | IESG | 3 | 380 | | Section 4.2.3.4 of RFCTBD2 | | | 381 +-------+-----------------------------------------------+------+----+ 383 Table 3: Initial Format Assignments 385 4.2.2. Updating Registrations 387 The registrant is always permitted to update a registration made on a 388 First Come First Served basis "subject to the same constraints and 389 review as with new registrations." IESG is permitted to update any 390 registration made on a First Come First Served basis, which normally 391 is done when the PoC cannot be reached in order to make necessary 392 updates. Examples where an update would be needed include, but are 393 not limited to: the email address or other contact information 394 becomes invalid; the reference to the format description becomes 395 obsolete or unavailable; and RFC1833 is updated or replaced in such a 396 way that the scope of uaddr formats changes, requiring additional 397 fields in the assignment. 399 Only IESG, on the advice of a Designated Expert, can update a 400 registration made on a Standards Action basis. 402 4.2.3. Uaddr Formats 404 4.2.3.1. Uaddr Format for System V Release 4 Loopback Transports 406 Although RFC1833 specifies the uaddr as the XDR data type string 407 (hence, limited to US-ASCII), implementations of the System V Release 408 4 loopback transports will use an opaque string of octets. Thus the 409 format of a loopback transport address is any non-zero length array 410 of octets. 412 4.2.3.2. Uaddr Format for Netid "-" 414 There is no address format for netid "-". This netid is apparently 415 for internal use for supporting some implementations of RFC1833. 417 4.2.3.3. Uaddr Format for Most IPv4 Transports 419 Most transport protocols that operate over IPv4 use 16 bit port 420 numbers, including RDMA [6], SCTP [7], TCP [13], and UDP [14]. The 421 format of the uaddr for the above 16 bit port transports (when used 422 over IPv4) is the US-ASCII string: 424 h1.h2.h3.h4.p1.p2 426 The prefix, "h1.h2.h3.h4", is the standard textual form for 427 representing an IPv4 address, which is always four octets long. 428 Assuming big-endian ordering, h1, h2, h3, and h4, are respectively, 429 the first through fourth octets each converted to ASCII-decimal. The 430 suffix, "p1.p2", is a textual form for representing a service port. 431 Assuming big-endian ordering, p1 and p2 are, respectively, the first 432 and second octets each converted to ASCII-decimal. For example, if a 433 host, in big-endian order, has an address in hexadecimal of 434 0xC0000207 and there is a service listening on, in big endian order, 435 port 0xCB51 (decimal 52049) then the complete uaddr is 436 "192.0.2.7.203.81". 438 4.2.3.4. Uaddr Format for Most IPv6 Transports 440 Most transport protocols that operate over IPv6 use 16 bit port 441 numbers, including RDMA [6], SCTP [7], TCP [13], and UDP [14]. The 442 format of the uaddr for the above 16 bit port transports (when used 443 over IPv6) is the US-ASCII string: 445 x1:x2:x3:x4:x5:x6:x7:x8.p1.p2 447 The suffix "p1.p2" is the service port, and is computed the same way 448 as with uaddrs for transports over IPv4 (see Section 4.2.3.3). The 449 prefix, "x1:x2:x3:x4:x5:x6:x7:x8", is the preferred textual form for 450 representing an IPv6 address as defined in Section 2.2 of RFC4291 451 [3]. Additionally, the two alternative forms specified in Section 452 2.2 of RFC4291 are also acceptable. 454 4.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6 456 As ICMP is not a true transport, there is no uaddr format for ICMP. 457 The netid assignments "icmp" and "icmp6" and their shared uaddr 458 "format" are listed to prevent any registrant from allocating the 459 netids "icmp" and "icmp6" for a purpose that would likely cause 460 confusion. 462 4.3. Cross Referencing Between the Netid and Format Registry 464 The last field of the netids registry is used to cross reference with 465 the last field of the format registry. IANA is under no obligation 466 to maintain same numeric value in cross references when updating each 467 registry; i.e. IANA is free to "re-number" these corresponding 468 fields. However, if IANA does so, both the netid and format 469 registries must be updated atomically. 471 4.4. Port Assignment for NFS over SCTP 473 Port TBD100 is assigned to NFS over SCTP for the sctp and sctp6 474 netids. 476 5. References 478 5.1. Normative References 480 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 481 Levels", RFC 2119, March 1997. 483 [2] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 484 RFC 1833, August 1995. 486 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 487 Architecture", RFC 4291, February 2006. 489 5.2. Informative References 491 [4] Srinivasan, R., "RPC: Remote Procedure Call Protocol 492 Specification Version 2", RFC 1831, August 1995. 494 [5] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 495 C., Eisler, M., and D. Noveck, "Network File System (NFS) 496 version 4 Protocol", RFC 3530, April 2003. 498 [6] Talpey, T. and B. Callaghan, "Remote Direct Memory Access 499 Transport for Remote Procedure Call", 500 draft-ietf-nfsv4-rpcrdma-09 (work in progress), December 2008. 502 [7] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 503 September 2007. 505 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 506 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 508 [9] Postel, J., "Internet Control Message Protocol", STD 5, 509 RFC 792, September 1981. 511 [10] American Telephone and Telegraph Company, "UNIX System V, 512 Release 4 Programmer's Guide: Networking Interfaces, ISBN 513 0139470786", 1990. 515 [11] Postel, J., "Internet Protocol", STD 5, RFC 791, 516 September 1981. 518 [12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 519 Specification", RFC 2460, December 1998. 521 [13] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 522 September 1981. 524 [14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 525 August 1980. 527 Appendix A. Acknowledgements 529 Lisa Dusseault, Lars Eggert, Pasi Eronen, Tim Polk, Juergen 530 Schoenwaelder, and Robert Sparks reviewed the document and gave 531 valuable feed back. 533 Appendix B. RFC Editor Notes 535 [RFC Editor: please remove this section prior to publication.] 537 [RFC Editor: Please replace occurrences of RFCTBD1 with the RFCxxxx 538 where xxxx is the RFC number assigned to the document referenced in 539 [6].] 541 [RFC Editor: Please replace occurrences of RFCTBD2 with the RFCyyyy 542 where yyyy is the RFC number assigned to this document.] 544 [IANA: Please use port 2049 for NFS/SCTP, as this is consistent with 545 NFS/TCP and NFS/UDP.] 547 [RFC Editor: Please replace occurrences of TBD100 with port assigned 548 to SCTP over NFS.] 550 Author's Address 552 Mike Eisler 553 NetApp 554 5765 Chase Point Circle 555 Colorado Springs, CO 80919 556 US 558 Phone: +1-719-599-9026 559 Email: mike@eisler.com