Network Working Group S. Zeng Internet-Draft Cisco Systems, Inc. Expires: May 5, 2006 D. R. Evans ARRIS International, Inc. November 2005 Hardware and Network Address Options for TFTP draft-evans-tftp-address-options-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 5, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Hardware Address and Network Address options carry the hardware address and network address respectively of a client device that performs a Trivial File Transfer Protocol (TFTP) request. Zeng & Evans Expires May 5, 2006 [Page 1] Internet-Draft TFTP Address Options November 2005 1. Introduction The Trivial File Transfer Protocol [2] (TFTP) is a simple protocol that allows a client to read a file from, or write a file to, a remote server. In some networks, a proxy relays requests and responses between a TFTP client and a TFTP server. A router may also be present between the client and the server. In these cases, addressing information that identifies the client and that may be required by the server for authentication, file-generation or other purposes may not be readily available to the server. The options defined in this document allow the client or the proxy to provide the needed address(es) to the server. The general mechanism used for adding options to TFTP messages is described in [4]. 2. Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [3]. 3. Format of the Hardware Address option The TFTP Read Request or Write Request packet is modified to include the hwaddr option. All named fields except "opc" are followed by a single-octet field containing the value zero. +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ | opc |filename| 0 | mode | 0 | hwaddr | 0 | ha | 0 | +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ opc The opcode field contains either a 1, for Read Requests, or 2, for Write Requests, as defined in [2]. filename The name of the file to be read or written, as defined in [2]. mode The mode of the file transfer: "netascii", "octet", or "mail", as defined in [2]. hwaddr The Hardware Address option, containing the case- insensitive string "hwaddr" in ASCII. Zeng & Evans Expires May 5, 2006 [Page 2] Internet-Draft TFTP Address Options November 2005 ha A hardware address. The format of hardware addresses is defined in Section 4. 4. Format of the Hardware Address A hardware address comprises two comma-separated ASCII fields: hardware type and the address value. hardware type A number representing the type of the hardware address. This document defines a single value, "1", representing an Ethernet address. address value A representation of the hardware address. This document defines a single format, to be used in the case that the hardware type has the value "1". In this case, that address MUST be an Ethernet MAC address in the case-insensitive form "xx:xx:xx:xx:xx:xx". 5. Format of the Network Address option The TFTP Read Request or Write Request packet is modified to include the netaddr option. All named fields except "opc" are followed by a single-octet field containing the value zero. +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ | opc |filename| 0 | mode | 0 | netaddr| 0 | na | 0 | +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ opc The opcode field contains either a 1, for Read Requests, or 2, for Write Requests, as defined in [2]. filename The name of the file to be read or written, as defined in [2]. mode The mode of the file transfer: "netascii", "octet", or "mail", as defined in [2]. netaddr The Network Address option, containing the case- insensitive string "netaddr" in ASCII. na A network address. The format of network addresses is defined in Section 6. 6. Format of the Network Address A network address comprises two comma-separated ASCII fields: network type and the address value. Zeng & Evans Expires May 5, 2006 [Page 3] Internet-Draft TFTP Address Options November 2005 network type A number representing the type of the network address. This document defines two values: "1" represents an IPv4 address; "2" represents an IPv6 address. address value A representation of the network address. This document defines two formats. If the network type has the value "1", the network address MUST be a dotted decimal IPv4 address as defined in [1] . If the network type has the value "2", the network address MUST be a case-insensitive IPv6 address in one of the formats specified by section 2.2 of [5]. 7. Option Acknowledgement [4] allows for the possibility that TFTP options will be acknowledged explicitly with an OACK packet. A TFTP server SHOULD NOT respond to the presence of a valid Hardware Address option or Network Address option by sending an OACK as defined in [4]. 8. Errors [4] allows for the possibility that TFTP options will contain errors. For the options defined in this document, the server SHOULD return a TFTP ERROR message with ErrorCode value 8 if any of the following occurs: 1. An error when parsing an option; 2. An unknown hardware or network type; 3. An incorrectly formatted hardware or network address. 9. Security Considerations TFTP provides no security safeguards; it relies on other layers to provide appropriate security where necessary. This document does not introduce any additional safeguards into TFTP. In the absence of other security measures, several possibilities exist for inappropriate behaviour: o A client could populate the options defined in this document with incorrect but legal values, which could cause the TFTP server to behave in an undesirable manner (for example, it might report an incorrect hardware address to a backoffice system). Zeng & Evans Expires May 5, 2006 [Page 4] Internet-Draft TFTP Address Options November 2005 o An attacker could replace correct option values with incorrect ones. o An attacker could insert incorrect option values into a request that originally did not use the options defined in this document. o An attacker could return an ERROR message to the client even though there was no ERROR in the request. o An attacker could insert an option into a reply that did not originally contain that option. 10. IANA Considerations This document has no actions for IANA. 11. Normative References [1] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, July 1990. [2] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Malkin, G. and A. Harkin, "TFTP Option Extension", RFC 2347, May 1998. [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. Zeng & Evans Expires May 5, 2006 [Page 5] Internet-Draft TFTP Address Options November 2005 Authors' Addresses Shengyou Zeng Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA Phone: +1 978.936.1609 Email: szeng@cisco.com D. R. Evans ARRIS International, Inc. 7912 Fairview Road Boulder, CO 80303 USA Phone: +1 303.494.0394 Email: N7DR@arrisi.com Zeng & Evans Expires May 5, 2006 [Page 6] Internet-Draft TFTP Address Options November 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zeng & Evans Expires May 5, 2006 [Page 7]