Internet DRAFT - draft-evans-tftp-address-options
draft-evans-tftp-address-options
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]
