idnits 2.17.1 draft-eastlake-ip-mime-10.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 223. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 229. ** 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 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 6735 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) -- Missing reference section? 'RFC 791' on line 99 looks like a reference -- Missing reference section? 'RFC 1661' on line 76 looks like a reference -- Missing reference section? 'RFC 1390' on line 76 looks like a reference -- Missing reference section? 'RFC 1149' on line 77 looks like a reference -- Missing reference section? 'RFC 2045' on line 79 looks like a reference -- Missing reference section? '2046' on line 79 looks like a reference -- Missing reference section? 'RFC 792' on line 120 looks like a reference -- Missing reference section? 'RFC 2821' on line 133 looks like a reference -- Missing reference section? '2822' on line 133 looks like a reference -- Missing reference section? 'RFC 826' on line 142 looks like a reference -- Missing reference section? 'RFC 1847' on line 165 looks like a reference -- Missing reference section? 'RFC 2046' on line 171 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Eastlake 3rd 2 Motorola Laboratories 3 Expires: April 2006 November 2005 5 IP over MIME 6 -- ---- ---- 7 9 Status of This Document 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Distribution of this document is unlimited. Comments should be sent 17 to the author. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 The MIME encoding of IP packets is specified so they can conveniently 42 be sent via MAIL, HTTP, etc. This may be convenient for transmitting 43 packets for analysis, debugging, monitoring, or creating application 44 level tunnels. 46 Acknowledgement 48 Helpful suggestions from Matt Crawford, Mike Ditto, Stanislav 49 Shalunov, and Mark Allman have been incorporated herein. 51 Table of Contents 53 Status of This Document....................................1 54 Copyright Notice...........................................1 55 Abstract...................................................1 57 Acknowledgement............................................2 58 Table of Contents..........................................2 60 1. Introduction............................................3 61 2. MIME Type Specification.................................3 62 3. Security Considerations.................................5 63 4. IANA Considerations.....................................5 65 Copyright and Disclaimers..................................6 67 Normative References.......................................7 68 Informative References.....................................7 69 Author's Address...........................................7 70 Expiration and File Name...................................8 72 1. Introduction 74 The Internet Protocol (IP [RFC 791]) has been profiled for 75 transmission over a wide variety of media including Ethernet [RFC 76 894], point to point circuits [RFC 1661], FDDI [RFC 1390], and even 77 avian carriers [RFC 1149]. One of the most popular encoding and 78 labeling (AKA, tagging and bagging) techniques defined for the TCP/IP 79 protocol suite is the MIME encoding [RFC 2045, 2046] used, for 80 example, in email, the web, and net news. This document specifies how 81 to transmit IP over MIME. 83 An unambiguous MIME encoding for IP datagrams is useful in their 84 transmission for monitoring, analysis, debugging, or illustrative 85 purposes. 87 In addition, IP over MIME can be used as one component in creating 88 application level tunnels. 90 2. MIME Type Specification 92 MIME media type name: APPLICATION 94 MIME subtype name: IP 96 Required parameters: version 98 version=n 99 This parameter exposes the IP Version number [RFC 791] in the 100 MIME Content-Type. 102 Optional parameters: dilation, address 104 dilation=nnn 105 Typically IP packets will be MIME labeled for transmission over 106 email or other application level protocols. Such transmission 107 is generally much slower than lower level network protocols. 108 While this is not usually a concern if a packet is just being 109 communicated for analysis, if such transmission is used to 110 establish a tunnel, the sender of a datagram may wish to advise 111 the recipient of the estimated rough time dilation factor. For 112 example, if datagrams typically take around a second and 113 occasionally up to ten seconds end-to-end but it is more like a 114 minute and occasionally up to ten minutes if they are MIME 115 encoded in email, a "dilation=60" parameter would be 116 reasonable. (Since it is a ratio of times, the dilation 117 parameter is dimensionless.) 119 Note: Although IP and TCP are defined as protocols only loosely 120 dependent on time. The IPv4 TTL [RFC 792], although originally 121 defined in terms of seconds, is usually implemented as a hop 122 count which is how the corresponding IPv6 field is defined [RFC 123 1752]. TCP requires a retransmission timer but has no 124 specified "time out" after which an unresponsive connection 125 must be torn down although all practical implementations have 126 such a time out. In the event that IP in MIME encapsulation is 127 being used for actual connectivity, it might be desireable to 128 scale all such timing by the dilation value if it has been 129 provided and is reasonable. 131 address=xxx 132 Full, if slow, IP connectivity via an application level 133 protocol such as SMTP [RFC 2821, 2822] might require that 134 routing, tunneling, and/or interface entries be installed at 135 each end. Routing entries would be best created or updated by 136 routing protocol messages and the establishment of tunnels is 137 beyond the scope of this MIME type specification. However, the 138 "address=" parameter enables the sender to optionally indicate 139 an IP address for return traffic to itself. This may only be 140 useful in cases where the sender knows an address that is 141 available for itself in the recipient's addressing environment. 142 It can be viewed as a replacement for ARP [RFC 826] on the 143 possible path to the source of the APPLICATION/IP object via 144 the same application level protocol. (A receiver of an 145 APPLICATION/IP object with an "address=" parameter might 146 reasonably require that it be authenticated as meeting their 147 policy as to from whom they would accept such information. For 148 example, they could ignore "address=" parameters unless the 149 APPLICATION/IP object was wrapped in an acceptable 150 MULTIPART/SIGNED [RFC 1847] authentication, although that 151 implies some trust relationship between the parties.) 153 Examples: 155 address="192.0.2.123" 157 address="2001:DB8::123" 159 Encoding considerations: Because of the binary nature of the body, 160 BASE64 transfer encoding should normally be used on transports 161 that do not support binary. 163 Security considerations: Care should be taken under any circumstance 164 where APPLICATION/IP content could be treated as a "live" 165 packet. MULTIPART/ENCRYPTED and MULTIPART/SIGNED [RFC 1847] 166 may be used to further secure and/or authenticate MIME packaged 167 IP traffic. 169 Interoperability considerations: See [draft-eastlake-ip-mime-*.txt]. 171 MULTIPART/MIXED [RFC 2046] may be used to package multiple IP 172 datagrams together. 174 Published specification: See [draft-eastlake-ip-mime-*.txt]. 176 Applications which use this media type: Not yet in use. 178 Additional information: (none) 180 Person & email address to contact for further information: 181 Donald E. Eastlake 3rd, Donald.Eastlake@motorola.com 183 Intended usage: LIMITED USE 185 Author/Change controller: IETF 187 3. Security Considerations 189 See security considerations in Section 2 above. 191 4. IANA Considerations 193 This document registers and specifies the APPLICATION/IP MIME type. 195 Copyright and Disclaimers 197 Copyright (C) The Internet Society (2005). This document is subject 198 to the rights, licenses and restrictions contained in BCP 78, and 199 except as set forth therein, the authors retain all their rights. 201 This document and the information contained herein are provided on an 202 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 203 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 204 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 205 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 206 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 207 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 209 The IETF takes no position regarding the validity or scope of any 210 Intellectual Property Rights or other rights that might be claimed to 211 pertain to the implementation or use of the technology described in 212 this document or the extent to which any license under such rights 213 might or might not be available; nor does it represent that it has 214 made any independent effort to identify any such rights. Information 215 on the procedures with respect to rights in RFC documents can be 216 found in BCP 78 and BCP 79. 218 Copies of IPR disclosures made to the IETF Secretariat and any 219 assurances of licenses to be made available, or the result of an 220 attempt made to obtain a general license or permission for the use of 221 such proprietary rights by implementers or users of this 222 specification can be obtained from the IETF on-line IPR repository at 223 http://www.ietf.org/ipr. 225 The IETF invites any interested party to bring to its attention any 226 copyrights, patents or patent applications, or other proprietary 227 rights that may cover technology that may be required to implement 228 this standard. Please address the information to the IETF at ietf- 229 ipr@ietf.org. 231 Normative References 233 RFC 791 - Postel, J., "Internet Protocol", STD 5, RFC 791, September 234 1981. 236 RFC 1752 - Bradner, S. and A. Mankin, "The Recommendation for the IP 237 Next Generation Protocol", RFC 1752, January 1995. 239 RFC 1847 - Galvin, J., Murphy, S., Crocker, S., and N. Freed, 240 "Security Multiparts for MIME: Multipart/Signed and 241 Multipart/Encrypted", RFC 1847, October 1995. 243 RFC 2045 - Freed, N. and N. Borenstein, "Multipurpose Internet Mail 244 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 245 2045, November 1996. 247 RFC 2046 - Freed, N. and N. Borenstein, "Multipurpose Internet Mail 248 Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. 250 Informative References 252 RFC 894 - Hornig, C., "Standard for the transmission of IP datagrams 253 over Ethernet networks", STD 41, RFC 894, April 1984. 255 RFC 1149 - Waitzman, D., "Standard for the transmission of IP 256 datagrams on avian carriers", RFC 1149, April 1990. 258 RFC 1390 - Katz, D., "Transmission of IP and ARP over FDDI Networks", 259 STD 36, RFC 1390, January 1993. 261 RFC 1661 - Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 262 RFC 1661, July 1994. 264 RFC 2821 - Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 265 April 2001. 267 RFC 2822 - Resnick, P., "Internet Message Format", RFC 2822, April 268 2001. 270 Author's Address 272 Donald E. Eastlake, 3rd 273 Motorola Laboratories 274 155 Beaver Street 275 Milford, MA 01757 USA 276 Telephone: +1 508-786-7554 (w) 277 email: Donald.Eastlake@motorola.com 279 Expiration and File Name 281 This draft expires May 2006. 283 Its file name is draft-eastlake-ip-mime-10.txt.