DHC Working Group T. Fujisaki Internet-Draft A. Matsumoto Intended status: Standards Track NTT Expires: August 5, 2007 Feb 2007 TCP Reaction to ICMPv6 Error Messages draft-fujisaki-tcpm-icmpv6-reaction-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 August 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract RFC1122 defines nodes TCP stack behavior for ICMPv4 error messages, but does not for ICMPv6. This document defines ICMPv6 message classification and node's TCP stack behavior for ICMPv6. 1. Introduction RFC1122 [RFC1122] section 4.2.3.9 describes nodes reaction to ICMPv4 Fujisaki & Matsumoto Expires August 5, 2007 [Page 1] Internet-Draft TCP Reaction to ICMPv6 Feb 2007 error message for TCP stack. However, currently, there are no clear corresponding definition about ICMPv6. This document defines nodes' TCP stack behavior to ICMPv6 error messages. 2. Definition of reactions to ICMPv4 in RFC1122 RFC1122 section 4.2.3.9 defines nodes behavior to ICMPv4 as follows: 4.2.3.9 ICMP Messages TCP MUST act on an ICMP error message passed up from the IP layer, directing it to the connection that created the error. The necessary demultiplexing information can be found in the IP header contained within the ICMP message. Source Quench TCP MUST react to a Source Quench by slowing transmission on the connection. The RECOMMENDED procedure is for a Source Quench to trigger a "slow start," as if a retransmission timeout had occurred. Destination Unreachable -- codes 0, 1, 5 Since these Unreachable messages indicate soft error conditions, TCP MUST NOT abort the connection, and it SHOULD make the information available to the application. DISCUSSION: TCP could report the soft error condition directly to the application layer with an upcall to the ERROR_REPORT routine, or it could merely note the message and report it to the application only when and if the TCP connection times out. Destination Unreachable -- codes 2-4 These are hard error conditions, so TCP SHOULD abort the connection. Time Exceeded -- codes 0, 1 This should be handled the same way as Destination Unreachable codes 0, 1, 5 (see above). Fujisaki & Matsumoto Expires August 5, 2007 [Page 2] Internet-Draft TCP Reaction to ICMPv6 Feb 2007 Parameter Problem This should be handled the same way as Destination Unreachable codes 0, 1, 5 (see above). Here, codes of ICMPv4 destination unreachable message defined in RFC792 [RFC0792] are: code 0: net unreachable; code 1: host unreachable; code 2: protocol unreachable; code 3: port unreachable; code 4: fragmentation needed and DF set; code 5: source route failed. 3. Definition of reactions to ICMPv6 In IPv6, types and codes of ICMPv6 error messages are defined in RFC4443 [RFC4443]. Those are: type 1: Destination Unreachable code 0: No route to destination code 1: Communication with destination administratively prohibited code 2: Beyond scope of source address code 3: Address unreachable code 4: Port unreachable code 5: Source address failed ingress/egress policy code 6: Reject route to destination type 2: Packet Too Big type 3: Time Exceeded code 0: Hop limit exceeded in transit code 1: Fragment reassembly time exceeded type 4: Parameter Problem code 0: Hop limit exceeded in transit code 1: Fragment reassembly time exceeded The document SOFTERROR [I-D.ietf-tcpm-tcp-soft-errors] describes the correspondence between ICMPv4 and ICMPv6 destination unreachable messages. Corresponding ICMPv6 definition is as follows. Fujisaki & Matsumoto Expires August 5, 2007 [Page 3] Internet-Draft TCP Reaction to ICMPv6 Feb 2007 TCP MUST act on an ICMPv6 error message passed up from the IP layer, directing it to the connection that created the error. The necessary demultiplexing information can be found in the IP header contained within the ICMPv6 message. Destination Unreachable -- codes 0,3 Since these Unreachable messages indicate soft error conditions, TCP MUST NOT abort the connection, and it SHOULD make the information available to the application. DISCUSSION: TCP could report the soft error condition directly to the application layer with an upcall to the ERROR_REPORT routine, or it could merely note the message and report it to the application only when and if the TCP connection times out. Destination Unreachable -- codes 1,2,4-6 These are hard error conditions, so TCP SHOULD abort the connection. Packet Too Big TCP should react to this message as described in RFC1981 [RFC1981]. Time Exceeded -- codes 0, 1 This should be handled the same way as Destination Unreachable codes 0, 3 (see above). Parameter Problem -- codes 0, 1 This should be handled the same way as Destination Unreachable codes 0, 3 (see above). 4. Discussion o When a node have multiple communication methods/protocols (e.g.an IPv6/IPv4 dual-stack node), and the node is in the connection establishment phase (SYN-SENT or SYN-RECEIVED state), it should abort current connection and try next methods/protocols even if it receives 'ICMPv6 soft error' messages. This modification is described in SOFTERROR. Fujisaki & Matsumoto Expires August 5, 2007 [Page 4] Internet-Draft TCP Reaction to ICMPv6 Feb 2007 o New ICMPv6 error messages definition should include reaction in upper layer. 5. Security Considerations As described in SOFTERROR security considerations section, there would be some security risks to process ICMPv6 error messages for established connections. Above document describes how to avoid these risks. 6. References 6.1. Normative References [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. 6.2. Informative References [I-D.ietf-tcpm-tcp-soft-errors] Gont, F., "TCP's Reaction to Soft Errors", draft-ietf-tcpm-tcp-soft-errors-03 (work in progress), January 2007. Fujisaki & Matsumoto Expires August 5, 2007 [Page 5] Internet-Draft TCP Reaction to ICMPv6 Feb 2007 Authors' Addresses Tomohiro Fujisaki NTT PF Lab 3-9-11 Midori-Cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 7351 Email: fujisaki.tomohiro@lab.ntt.co.jp Arifumi Matsumoto NTT PF Lab 3-9-11 Midori-Cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 3334 Email: arifumi@nttv6.net Fujisaki & Matsumoto Expires August 5, 2007 [Page 6] Internet-Draft TCP Reaction to ICMPv6 Feb 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Fujisaki & Matsumoto Expires August 5, 2007 [Page 7]