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]
