Internet DRAFT - draft-eastlake-ip-mime
draft-eastlake-ip-mime
INTERNET-DRAFT D. Eastlake 3rd
Motorola Laboratories
Expires: April 2006 November 2005
IP over MIME
-- ---- ----
<draft-eastlake-ip-mime-10.txt>
Status of This Document
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.
Distribution of this document is unlimited. Comments should be sent
to the author.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The MIME encoding of IP packets is specified so they can conveniently
be sent via MAIL, HTTP, etc. This may be convenient for transmitting
packets for analysis, debugging, monitoring, or creating application
level tunnels.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT IP over MIME November 2005
Acknowledgement
Helpful suggestions from Matt Crawford, Mike Ditto, Stanislav
Shalunov, and Mark Allman have been incorporated herein.
Table of Contents
Status of This Document....................................1
Copyright Notice...........................................1
Abstract...................................................1
Acknowledgement............................................2
Table of Contents..........................................2
1. Introduction............................................3
2. MIME Type Specification.................................3
3. Security Considerations.................................5
4. IANA Considerations.....................................5
Copyright and Disclaimers..................................6
Normative References.......................................7
Informative References.....................................7
Author's Address...........................................7
Expiration and File Name...................................8
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT IP over MIME November 2005
1. Introduction
The Internet Protocol (IP [RFC 791]) has been profiled for
transmission over a wide variety of media including Ethernet [RFC
894], point to point circuits [RFC 1661], FDDI [RFC 1390], and even
avian carriers [RFC 1149]. One of the most popular encoding and
labeling (AKA, tagging and bagging) techniques defined for the TCP/IP
protocol suite is the MIME encoding [RFC 2045, 2046] used, for
example, in email, the web, and net news. This document specifies how
to transmit IP over MIME.
An unambiguous MIME encoding for IP datagrams is useful in their
transmission for monitoring, analysis, debugging, or illustrative
purposes.
In addition, IP over MIME can be used as one component in creating
application level tunnels.
2. MIME Type Specification
MIME media type name: APPLICATION
MIME subtype name: IP
Required parameters: version
version=n
This parameter exposes the IP Version number [RFC 791] in the
MIME Content-Type.
Optional parameters: dilation, address
dilation=nnn
Typically IP packets will be MIME labeled for transmission over
email or other application level protocols. Such transmission
is generally much slower than lower level network protocols.
While this is not usually a concern if a packet is just being
communicated for analysis, if such transmission is used to
establish a tunnel, the sender of a datagram may wish to advise
the recipient of the estimated rough time dilation factor. For
example, if datagrams typically take around a second and
occasionally up to ten seconds end-to-end but it is more like a
minute and occasionally up to ten minutes if they are MIME
encoded in email, a "dilation=60" parameter would be
reasonable. (Since it is a ratio of times, the dilation
parameter is dimensionless.)
Note: Although IP and TCP are defined as protocols only loosely
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT IP over MIME November 2005
dependent on time. The IPv4 TTL [RFC 792], although originally
defined in terms of seconds, is usually implemented as a hop
count which is how the corresponding IPv6 field is defined [RFC
1752]. TCP requires a retransmission timer but has no
specified "time out" after which an unresponsive connection
must be torn down although all practical implementations have
such a time out. In the event that IP in MIME encapsulation is
being used for actual connectivity, it might be desireable to
scale all such timing by the dilation value if it has been
provided and is reasonable.
address=xxx
Full, if slow, IP connectivity via an application level
protocol such as SMTP [RFC 2821, 2822] might require that
routing, tunneling, and/or interface entries be installed at
each end. Routing entries would be best created or updated by
routing protocol messages and the establishment of tunnels is
beyond the scope of this MIME type specification. However, the
"address=" parameter enables the sender to optionally indicate
an IP address for return traffic to itself. This may only be
useful in cases where the sender knows an address that is
available for itself in the recipient's addressing environment.
It can be viewed as a replacement for ARP [RFC 826] on the
possible path to the source of the APPLICATION/IP object via
the same application level protocol. (A receiver of an
APPLICATION/IP object with an "address=" parameter might
reasonably require that it be authenticated as meeting their
policy as to from whom they would accept such information. For
example, they could ignore "address=" parameters unless the
APPLICATION/IP object was wrapped in an acceptable
MULTIPART/SIGNED [RFC 1847] authentication, although that
implies some trust relationship between the parties.)
Examples:
address="192.0.2.123"
address="2001:DB8::123"
Encoding considerations: Because of the binary nature of the body,
BASE64 transfer encoding should normally be used on transports
that do not support binary.
Security considerations: Care should be taken under any circumstance
where APPLICATION/IP content could be treated as a "live"
packet. MULTIPART/ENCRYPTED and MULTIPART/SIGNED [RFC 1847]
may be used to further secure and/or authenticate MIME packaged
IP traffic.
Interoperability considerations: See [draft-eastlake-ip-mime-*.txt].
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT IP over MIME November 2005
MULTIPART/MIXED [RFC 2046] may be used to package multiple IP
datagrams together.
Published specification: See [draft-eastlake-ip-mime-*.txt].
Applications which use this media type: Not yet in use.
Additional information: (none)
Person & email address to contact for further information:
Donald E. Eastlake 3rd, Donald.Eastlake@motorola.com
Intended usage: LIMITED USE
Author/Change controller: IETF
3. Security Considerations
See security considerations in Section 2 above.
4. IANA Considerations
This document registers and specifies the APPLICATION/IP MIME type.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT IP over MIME November 2005
Copyright and Disclaimers
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.
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.
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.
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT IP over MIME November 2005
Normative References
RFC 791 - Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
RFC 1752 - Bradner, S. and A. Mankin, "The Recommendation for the IP
Next Generation Protocol", RFC 1752, January 1995.
RFC 1847 - Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
RFC 2045 - Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
2045, November 1996.
RFC 2046 - Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Informative References
RFC 894 - Hornig, C., "Standard for the transmission of IP datagrams
over Ethernet networks", STD 41, RFC 894, April 1984.
RFC 1149 - Waitzman, D., "Standard for the transmission of IP
datagrams on avian carriers", RFC 1149, April 1990.
RFC 1390 - Katz, D., "Transmission of IP and ARP over FDDI Networks",
STD 36, RFC 1390, January 1993.
RFC 1661 - Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
RFC 2821 - Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
RFC 2822 - Resnick, P., "Internet Message Format", RFC 2822, April
2001.
Author's Address
Donald E. Eastlake, 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT IP over MIME November 2005
Telephone: +1 508-786-7554 (w)
email: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires May 2006.
Its file name is draft-eastlake-ip-mime-10.txt.
D. Eastlake 3rd [Page 8]
