idnits 2.17.1 draft-evans-tftp-address-options-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 251. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 2005) is 6730 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) ** Downref: Normative reference to an Informational RFC: RFC 1166 (ref. '1') ** Obsolete normative reference: RFC 3513 (ref. '5') (Obsoleted by RFC 4291) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Zeng 3 Internet-Draft Cisco Systems, Inc. 4 Expires: May 5, 2006 D. R. Evans 5 ARRIS International, Inc. 6 November 2005 8 Hardware and Network Address Options for TFTP 9 draft-evans-tftp-address-options-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other 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 at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 5, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The Hardware Address and Network Address options carry the hardware 43 address and network address respectively of a client device that 44 performs a Trivial File Transfer Protocol (TFTP) request. 46 1. Introduction 48 The Trivial File Transfer Protocol [2] (TFTP) is a simple protocol 49 that allows a client to read a file from, or write a file to, a 50 remote server. 52 In some networks, a proxy relays requests and responses between a 53 TFTP client and a TFTP server. A router may also be present between 54 the client and the server. In these cases, addressing information 55 that identifies the client and that may be required by the server for 56 authentication, file-generation or other purposes may not be readily 57 available to the server. The options defined in this document allow 58 the client or the proxy to provide the needed address(es) to the 59 server. 61 The general mechanism used for adding options to TFTP messages is 62 described in [4]. 64 2. Terminology 66 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 67 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 68 interpreted as described in [3]. 70 3. Format of the Hardware Address option 72 The TFTP Read Request or Write Request packet is modified to include 73 the hwaddr option. All named fields except "opc" are followed by a 74 single-octet field containing the value zero. 76 +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ 77 | opc |filename| 0 | mode | 0 | hwaddr | 0 | ha | 0 | 78 +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ 80 opc The opcode field contains either a 1, for Read 81 Requests, or 2, for Write Requests, as defined in 82 [2]. 83 filename The name of the file to be read or written, as 84 defined in [2]. 85 mode The mode of the file transfer: "netascii", 86 "octet", or "mail", as defined in [2]. 87 hwaddr The Hardware Address option, containing the case- 88 insensitive string "hwaddr" in ASCII. 90 ha A hardware address. The format of hardware 91 addresses is defined in Section 4. 93 4. Format of the Hardware Address 95 A hardware address comprises two comma-separated ASCII fields: 96 hardware type and the address value. 98 hardware type A number representing the type of the hardware 99 address. This document defines a single value, 100 "1", representing an Ethernet address. 101 address value A representation of the hardware address. This 102 document defines a single format, to be used in 103 the case that the hardware type has the value 104 "1". In this case, that address MUST be an 105 Ethernet MAC address in the case-insensitive form 106 "xx:xx:xx:xx:xx:xx". 108 5. Format of the Network Address option 110 The TFTP Read Request or Write Request packet is modified to include 111 the netaddr option. All named fields except "opc" are followed by a 112 single-octet field containing the value zero. 114 +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ 115 | opc |filename| 0 | mode | 0 | netaddr| 0 | na | 0 | 116 +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ 118 opc The opcode field contains either a 1, for Read 119 Requests, or 2, for Write Requests, as defined in 120 [2]. 121 filename The name of the file to be read or written, as 122 defined in [2]. 123 mode The mode of the file transfer: "netascii", 124 "octet", or "mail", as defined in [2]. 125 netaddr The Network Address option, containing the case- 126 insensitive string "netaddr" in ASCII. 127 na A network address. The format of network 128 addresses is defined in Section 6. 130 6. Format of the Network Address 132 A network address comprises two comma-separated ASCII fields: network 133 type and the address value. 135 network type A number representing the type of the network 136 address. This document defines two values: "1" 137 represents an IPv4 address; "2" represents an 138 IPv6 address. 139 address value A representation of the network address. This 140 document defines two formats. If the network 141 type has the value "1", the network address MUST 142 be a dotted decimal IPv4 address as defined in 143 [1] . If the network type has the value "2", the 144 network address MUST be a case-insensitive IPv6 145 address in one of the formats specified by 146 section 2.2 of [5]. 148 7. Option Acknowledgement 150 [4] allows for the possibility that TFTP options will be acknowledged 151 explicitly with an OACK packet. A TFTP server SHOULD NOT respond to 152 the presence of a valid Hardware Address option or Network Address 153 option by sending an OACK as defined in [4]. 155 8. Errors 157 [4] allows for the possibility that TFTP options will contain errors. 158 For the options defined in this document, the server SHOULD return a 159 TFTP ERROR message with ErrorCode value 8 if any of the following 160 occurs: 162 1. An error when parsing an option; 163 2. An unknown hardware or network type; 164 3. An incorrectly formatted hardware or network address. 166 9. Security Considerations 168 TFTP provides no security safeguards; it relies on other layers to 169 provide appropriate security where necessary. This document does not 170 introduce any additional safeguards into TFTP. In the absence of 171 other security measures, several possibilities exist for 172 inappropriate behaviour: 174 o A client could populate the options defined in this document with 175 incorrect but legal values, which could cause the TFTP server to 176 behave in an undesirable manner (for example, it might report an 177 incorrect hardware address to a backoffice system). 179 o An attacker could replace correct option values with incorrect 180 ones. 181 o An attacker could insert incorrect option values into a request 182 that originally did not use the options defined in this document. 183 o An attacker could return an ERROR message to the client even 184 though there was no ERROR in the request. 185 o An attacker could insert an option into a reply that did not 186 originally contain that option. 188 10. IANA Considerations 190 This document has no actions for IANA. 192 11. Normative References 194 [1] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", 195 RFC 1166, July 1990. 197 [2] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, 198 July 1992. 200 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 201 Levels", BCP 14, RFC 2119, March 1997. 203 [4] Malkin, G. and A. Harkin, "TFTP Option Extension", RFC 2347, 204 May 1998. 206 [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 207 Addressing Architecture", RFC 3513, April 2003. 209 Authors' Addresses 211 Shengyou Zeng 212 Cisco Systems, Inc. 213 1414 Massachusetts Avenue 214 Boxborough, MA 01719 215 USA 217 Phone: +1 978.936.1609 218 Email: szeng@cisco.com 220 D. R. Evans 221 ARRIS International, Inc. 222 7912 Fairview Road 223 Boulder, CO 80303 224 USA 226 Phone: +1 303.494.0394 227 Email: N7DR@arrisi.com 229 Intellectual Property Statement 231 The IETF takes no position regarding the validity or scope of any 232 Intellectual Property Rights or other rights that might be claimed to 233 pertain to the implementation or use of the technology described in 234 this document or the extent to which any license under such rights 235 might or might not be available; nor does it represent that it has 236 made any independent effort to identify any such rights. Information 237 on the procedures with respect to rights in RFC documents can be 238 found in BCP 78 and BCP 79. 240 Copies of IPR disclosures made to the IETF Secretariat and any 241 assurances of licenses to be made available, or the result of an 242 attempt made to obtain a general license or permission for the use of 243 such proprietary rights by implementers or users of this 244 specification can be obtained from the IETF on-line IPR repository at 245 http://www.ietf.org/ipr. 247 The IETF invites any interested party to bring to its attention any 248 copyrights, patents or patent applications, or other proprietary 249 rights that may cover technology that may be required to implement 250 this standard. Please address the information to the IETF at 251 ietf-ipr@ietf.org. 253 Disclaimer of Validity 255 This document and the information contained herein are provided on an 256 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 257 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 258 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 259 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 260 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 261 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 263 Copyright Statement 265 Copyright (C) The Internet Society (2005). This document is subject 266 to the rights, licenses and restrictions contained in BCP 78, and 267 except as set forth therein, the authors retain all their rights. 269 Acknowledgment 271 Funding for the RFC Editor function is currently provided by the 272 Internet Society.