summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6918.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6918.txt')
-rw-r--r--doc/rfc/rfc6918.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc6918.txt b/doc/rfc/rfc6918.txt
new file mode 100644
index 0000000..109e08d
--- /dev/null
+++ b/doc/rfc/rfc6918.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) F. Gont
+Request for Comments: 6918 UTN-FRH / SI6 Networks
+Obsoletes: 1788 C. Pignataro
+Updates: 792, 950 Cisco Systems
+Category: Standards Track April 2013
+ISSN: 2070-1721
+
+
+ Formally Deprecating Some ICMPv4 Message Types
+
+Abstract
+
+ A number of ICMPv4 message types have become obsolete in practice,
+ but have never been formally deprecated. This document deprecates
+ such ICMPv4 message types, thus cleaning up the corresponding IANA
+ registry. Additionally, it updates RFC 792 and RFC 950, obsoletes
+ RFC 1788, and requests the RFC Editor to change the status of RFC
+ 1788 to Historic.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6918.
+
+Copyright Notice
+
+ Copyright (c) 2013 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Gont & Pignataro Standards Track [Page 1]
+
+RFC 6918 Deprecating Some ICMPv4 Messages April 2013
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Discussion of Deprecated ICMPv4 Message Types . . . . . . . . . 3
+ 2.1. Alternate Host Address (Type 6) . . . . . . . . . . . . . . 3
+ 2.2. Information Request (Type 15) . . . . . . . . . . . . . . . 3
+ 2.3. Information Reply (Type 16) . . . . . . . . . . . . . . . . 3
+ 2.4. Address Mask Request (Type 17) . . . . . . . . . . . . . . 3
+ 2.5. Address Mask Reply (Type 18) . . . . . . . . . . . . . . . 3
+ 2.6. Traceroute (Type 30) . . . . . . . . . . . . . . . . . . . 3
+ 2.7. Datagram Conversion Error (Type 31) . . . . . . . . . . . . 4
+ 2.8. Mobile Host Redirect (Type 32) . . . . . . . . . . . . . . 4
+ 2.9. IPv6 Where-Are-You (Type 33) . . . . . . . . . . . . . . . 4
+ 2.10. IPv6 I-Am-Here (Type 34) . . . . . . . . . . . . . . . . . 4
+ 2.11. Mobile Registration Request (Type 35) . . . . . . . . . . . 4
+ 2.12. Mobile Registration Reply (Type 36) . . . . . . . . . . . . 4
+ 2.13. Domain Name Request (Type 37) . . . . . . . . . . . . . . . 4
+ 2.14. Domain Name Reply (Type 38) . . . . . . . . . . . . . . . . 5
+ 2.15. SKIP (Type 39) . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Changing the Status of RFC 1788 to Historic . . . . . . . . . . 6
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 6
+
+1. Introduction
+
+ A number of ICMPv4 [RFC0792] message types have been specified over
+ the years. A number of these message types have become obsolete in
+ practice, but have never been formally deprecated. This document
+ deprecates such ICMPv4 message types, "cleaning up" the corresponding
+ IANA registry. Additionally, it updates RFC 792 and RFC 950,
+ obsoletes RFC 1788, and requests the RFC Editor to change the status
+ of RFC 1788 to Historic.
+
+ Section 2 discusses each of the obsoleted ICMPv4 messages. Section 4
+ requests the RFC Editor to change the status of RFC 1788 to Historic.
+
+
+
+
+
+
+
+
+
+
+
+
+Gont & Pignataro Standards Track [Page 2]
+
+RFC 6918 Deprecating Some ICMPv4 Messages April 2013
+
+
+2. Discussion of Deprecated ICMPv4 Message Types
+
+ The following subsections discuss the details of those ICMPv4 message
+ types being deprecated, based on publicly available information
+ and/or information provided by the requester of the corresponding
+ assignment.
+
+2.1. Alternate Host Address (Type 6)
+
+ There is no publicly available information about this message type.
+
+2.2. Information Request (Type 15)
+
+ This message type is specified in [RFC0792]. However, other
+ mechanisms (such as DHCP [RFC2131]) have superseded this message type
+ for the purpose of host configuration.
+
+2.3. Information Reply (Type 16)
+
+ This message type is specified in [RFC0792]. However, other
+ mechanisms (such as DHCP [RFC2131]) have superseded this message type
+ for the purpose of host configuration.
+
+2.4. Address Mask Request (Type 17)
+
+ This message type is specified in [RFC0950] and was meant to provide
+ a means to obtain the subnet mask. However, other mechanisms (such
+ as DHCP [RFC2131]) have superseded this message type for the purpose
+ of host configuration.
+
+2.5. Address Mask Reply (Type 18)
+
+ This message type is specified in [RFC0950] and was meant to provide
+ a means to obtain the subnet mask. However, other mechanisms (such
+ as DHCP [RFC2131]) have superseded this message type for the purpose
+ of host configuration.
+
+2.6. Traceroute (Type 30)
+
+ This message type is specified in [RFC1393] and was meant to provide
+ an alternative means to discover the path to a destination system.
+ This message type has never been widely deployed. The status of
+ [RFC1393] has been changed to Historic by [RFC6814], and the
+ corresponding option this message type relies on (Traceroute, Type
+ 82) has been formally obsoleted by [RFC6814].
+
+
+
+
+
+
+Gont & Pignataro Standards Track [Page 3]
+
+RFC 6918 Deprecating Some ICMPv4 Messages April 2013
+
+
+2.7. Datagram Conversion Error (Type 31)
+
+ This message type was originally meant to report conversion errors in
+ the TP/IX [RFC1475] protocol. However, TP/IX was never widely
+ implemented or deployed, and the status of [RFC1475] is Historic.
+
+2.8. Mobile Host Redirect (Type 32)
+
+ This message type was originally specified as part of an experimental
+ protocol for IP Mobile Hosts [CMU-MOBILE]. However, it was never
+ widely implemented or deployed.
+
+2.9. IPv6 Where-Are-You (Type 33)
+
+ This message type was originally specified in [SIMPSON-DISCOV] for
+ the purpose of identification of adjacent IPv6 nodes. It was never
+ widely deployed or implemented.
+
+2.10. IPv6 I-Am-Here (Type 34)
+
+ This message type was originally specified in [SIMPSON-DISCOV] for
+ the purpose of identification of adjacent IPv6 nodes. It was never
+ widely deployed or implemented.
+
+2.11. Mobile Registration Request (Type 35)
+
+ This message type was originally meant for transparent routing of
+ IPv6 datagrams to Mobile Nodes [SIMPSON-MOBILITY]. It was never
+ widely deployed or implemented.
+
+2.12. Mobile Registration Reply (Type 36)
+
+ This message type was originally meant for transparent routing of
+ IPv6 datagrams to Mobile Nodes [SIMPSON-MOBILITY]. It was never
+ widely deployed or implemented.
+
+2.13. Domain Name Request (Type 37)
+
+ This message type was originally specified in [RFC1788] for the
+ purpose of learning the Fully Qualified Domain Name associated with
+ an IP address. This message type was never widely deployed or
+ implemented.
+
+
+
+
+
+
+
+
+
+Gont & Pignataro Standards Track [Page 4]
+
+RFC 6918 Deprecating Some ICMPv4 Messages April 2013
+
+
+2.14. Domain Name Reply (Type 38)
+
+ This message type was originally specified in [RFC1788] for the
+ purpose of learning the Fully Qualified Domain Name associated with
+ an IP address. This message type was never widely deployed or
+ implemented.
+
+2.15. SKIP (Type 39)
+
+ This message type was originally specified in [SKIP-ADP] for
+ informing supported capabilities in the SKIP [SKIP] protocol. This
+ message type was never widely deployed or implemented.
+
+3. IANA Considerations
+
+ The "Internet Control Message Protocol (ICMP) Parameters" registry
+ [IANA-ICMP] contains the list of the currently assigned ICMP message
+ Types.
+
+ This document formally deprecates the following ICMP message Types
+ and requests IANA to mark them as such in the corresponding registry
+ [IANA-ICMP]:
+
+ o Alternate Host Address (Type 6)
+
+ o Information Request (Type 15)
+
+ o Information Reply (Type 16)
+
+ o Address Mask Request (Type 17)
+
+ o Address Mask Reply (Type 18)
+
+ o Traceroute (Type 30)
+
+ o Datagram Conversion Error (Type 31)
+
+ o Mobile Host Redirect (Type 32)
+
+ o IPv6 Where-Are-You (Type 33)
+
+ o IPv6 I-Am-Here (Type 34)
+
+ o Mobile Registration Request (Type 35)
+
+ o Mobile Registration Reply (Type 36)
+
+ o Domain Name Request (Type 37)
+
+
+
+Gont & Pignataro Standards Track [Page 5]
+
+RFC 6918 Deprecating Some ICMPv4 Messages April 2013
+
+
+ o Domain Name Reply (Type 38)
+
+ o SKIP (Type 39)
+
+ The ICMPv4 Source Quench Message (Type 4) has already been
+ deprecated by [RFC6633].
+
+4. Changing the Status of RFC 1788 to Historic
+
+ This document requests the RFC Editor to change the status of
+ [RFC1788] to Historic.
+
+ Both [RFC1385] and [RFC1393] already have a status of Historic.
+ The status of other RFCs (such as [RFC0792] and [RFC0950]) is not
+ changed since other parts of these documents are still current.
+
+5. Security Considerations
+
+ This document does not modify the security properties of the ICMPv4
+ message types being deprecated. However, formally deprecating these
+ message types serves as a basis for, e.g., filtering these packets.
+
+6. Acknowledgments
+
+ The authors would like to thank Ron Bonica and Joel Halpern for their
+ guidance.
+
+7. References
+
+7.1. Normative References
+
+ [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
+ RFC 792, September 1981.
+
+ [RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some
+ IPv4 Options", RFC 6814, November 2012.
+
+7.2. Informative References
+
+ [CMU-MOBILE] Johnson, D., "Transparent Internet Routing for IP Mobile
+ Hosts", Work in Progress, July 1993.
+
+ [IANA-ICMP] Internet Assigned Numbers Authority, "Internet Control
+ Message Protocol (ICMP) Parameters", September 2012,
+ <http://www.iana.org/assignments/icmp-parameters>.
+
+ [RFC0950] Mogul, J. and J. Postel, "Internet Standard Subnetting
+ Procedure", STD 5, RFC 950, August 1985.
+
+
+
+Gont & Pignataro Standards Track [Page 6]
+
+RFC 6918 Deprecating Some ICMPv4 Messages April 2013
+
+
+ [RFC1385] Wang, Z., "EIP: The Extended Internet Protocol",
+ RFC 1385, November 1992.
+
+ [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393,
+ January 1993.
+
+ [RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
+ June 1993.
+
+ [RFC1788] Simpson, W., "ICMP Domain Name Messages", RFC 1788,
+ April 1995.
+
+ [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
+ RFC 2131, March 1997.
+
+ [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages",
+ RFC 6633, May 2012.
+
+ [SIMPSON-DISCOV]
+ Simpson, W., "IPv6 Neighbor Discovery -- ICMP Message
+ Formats", Work in Progress, January 1995.
+
+ [SIMPSON-MOBILITY]
+ Simpson, W., "IPv6 Mobility Support", Work in Progress,
+ November 1994.
+
+ [SKIP] Aziz, A., Markson, T., and H. Prafullchandra, "Simple
+ Key-Management For Internet Protocols (SKIP)", Work
+ in Progress, December 1995.
+
+ [SKIP-ADP] Aziz, A., Markson, T., and H. Prafullchandra, "SKIP
+ Algorithm Discovery Protocol", Work in Progress,
+ December 1995.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont & Pignataro Standards Track [Page 7]
+
+RFC 6918 Deprecating Some ICMPv4 Messages April 2013
+
+
+Authors' Addresses
+
+ Fernando Gont
+ UTN-FRH / SI6 Networks
+ Evaristo Carriego 2644
+ Haedo, Provincia de Buenos Aires 1706
+ Argentina
+
+ Phone: +54 11 4650 8472
+ EMail: fgont@si6networks.com
+ URI: http://www.si6networks.com
+
+
+ Carlos Pignataro
+ Cisco Systems
+ 7200-12 Kit Creek Road
+ Research Triangle Park, NC 27709
+ US
+
+ EMail: cpignata@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont & Pignataro Standards Track [Page 8]
+