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]