Behave WG T. Savolainen Internet-Draft R. Denis-Courmont Intended status: Standards Track Nokia Corporation Expires: November 27, 2009 May 26, 2009 Generation of ICMPv6 Echo Replies for Teredo Clients draft-denis-icmpv6-generation-for-teredo-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 November 27, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Teredo uses return routing to discover the closest Teredo relay corresponding to any given peer. Discovery is achieved by sending an ICMPv6 Echo Request and waiting for the appropriate relay to forward Savolainen & Denis-Courmont Expires November 27, 2009 [Page 1] Internet-Draft ICMPv6 Echo Replies for Teredo May 2009 the ICMPv6 Echo Reply back. Unanswered ICMPv6 Echo Requests make Teredo clients assume that the peer is unreachable. This document identifies two scenarios where a middlebox should detect the lack of ICMPv6 Echo Reply and craft one toward the Teredo client in order to avoid possibly erroneous peer unreachability assumptions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Behavioral requirements for middleboxes . . . . . . . . . . . . 4 2.1. Configuration options . . . . . . . . . . . . . . . . . . . 4 2.2. Protocol translators . . . . . . . . . . . . . . . . . . . 4 2.3. IPv6 firewalls . . . . . . . . . . . . . . . . . . . . . . 5 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Savolainen & Denis-Courmont Expires November 27, 2009 [Page 2] Internet-Draft ICMPv6 Echo Replies for Teredo May 2009 1. Introduction The Teredo protocol [RFC4380] uses return routing to discover the Teredo relay corresponding to any given non-Teredo IPv6 peer. Specifically, a Teredo client sends an ICMPv6 Echo Request to the peer and waits for a Teredo relay to forward the corresponding ICMPv6 Echo Reply back. If this does not happen within a reasonable delay, the Teredo client assumes that the peer cannot be reached via Teredo. In the IPv6 Internet, this normally works fine, as all IPv6 nodes implement sending of ICMPv6 Echo Replies in response to ICMPv6 Echo Requests. However, two scenarios have been identified where this Teredo procedure might fail: 1) When a NAT-PT [RFC2766] or NAT64 [I-D.bagnulo-behave-nat64] protocol translator is on the path: the translator translates an IPv6 ICMPv6 Echo Request originating from Teredo client into an IPv4 ICMPv4 Echo Request and forwards it toward the IPv4 peer. However, in the IPv4 realm, ICMPv4 does not always work reliably. If the IPv4 peer does not reply with an ICMPv4 Echo Reply for any reason (for example, ICMPv4 Echo Replies are disabled or filtered by an IPv4 firewall), the Teredo client will not get any ICMPv6 Echo Reply response packet back, and thus it will determine that the peer is unreachable. That implies that transport sessions, which otherwise could have succeeded, will not even be initiated. Effectively IPv4 nodes behind protocol translators that do not successfully respond with ICMPv4 Echo Replies cannot be reachable by Teredo clients. 2) When an IPv6 firewall blocks ICMPv6 Echo Requests or Replies: If a Teredo client sends an ICMPv6 Echo Request to a non-Teredo IPv6 destination, yet does not receive any ICMPv6 Echo Reply back, because IPv6 firewall discard either packet, the Teredo client will determine that the peer cannot be reached. As a consequence, it will not even try to route packets toward the destination. In both cases, Teredo-based IPv6 flows fail. That will either cause delays in transport-layer connection setup, if the host is able to fallback to other source addresses, or complete connection failure in other cases. This document proposes a solution where a middlebox detects the problem and helps Teredo client to proceed by generating ICMPv6 Echo Reply for it. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Savolainen & Denis-Courmont Expires November 27, 2009 [Page 3] Internet-Draft ICMPv6 Echo Replies for Teredo May 2009 2. Behavioral requirements for middleboxes A middlebox implementing this specification shall track ICMPv6 Echo Requests originated from Teredo hosts. The middlebox shall generate ICMPv6 Echo Replies when determined necessary. While generating the reply, the middlebox allows Teredo clients to go forward with their connectivity establishment procedures. A middlebox can determine the ICMPv6 Echo Request is coming from a Teredo client from the packet's IPv6 source address prefix, 2001: 0000::/32, as described in RFC4380 [RFC4380]. 2.1. Configuration options The following options related to ICMPv6 Echo Reply generation SHOULD be configurable on a middlebox: o Enable/disable: ICMPv6 Echo Reply generation for Teredo clients. o Enable/disable: Forced ICMPv6 Echo Reply generation for Teredo clients. If enabled, the middlebox shall always immediately generate an ICMPv6 Echo Reply when it detects an ICMPv6 Echo Request originated from a Teredo client. If disabled, the middlebox shall generate ICMPv6 Echo Reply when one has been determined missing. 2.2. Protocol translators As the NAT-PT [RFC2766] or NAT64 [I-D.bagnulo-behave-nat64] protocol translator entity is always on the return data path, it can detect whether an ICMPv4 Echo Reply is coming from the IPv4 peer and, if not, is able to generate an ICMPv6 Echo Reply toward the Teredo client. The translator must not assume that lack of an ICMPv4 Echo Reply implies unavailability of the IPv4 peer. A protocol translator SHALL record the state of any translated ICMPv6 Echo Request, and if no ICMPv4 Echo Reply is received within [TBD time], or if a retransmitted ICMPv6 Echo Request is detected, an ICMPv6 Echo Reply MUST be generated. The protocol translator SHALL remove the state after the ICMPv4 Echo Reply is received and translated, and the ICMPv6 Echo Reply is generated, or TBD seconds since the last ICMPv6 Echo Request reception without retransmission. A protocol translator SHALL by default have automatic ICMPv6 Echo Reply generation enabled. In case forced ICMPv6 Echo Reply generation is enabled, ICMPv6 Echo Requests shall continue to be translated into ICMPv4 Echo Requests. Savolainen & Denis-Courmont Expires November 27, 2009 [Page 4] Internet-Draft ICMPv6 Echo Replies for Teredo May 2009 Also, any received ICMPv4 Echo Reply shall be translated into an ICMPv6 Echo Reply. In that case, the Teredo client may receive duplicate ICMPv6 Echo Replies. 2.3. IPv6 firewalls By default IPv6 firewall MUST NOT generate ICMPv6 Echo Replies, because the lack of ICMPv6 Echo Reply should continue to indicate that the peer is unreachable, and because IPv6 firewall might not be on the return data path of ICMPv6 Echo Replies. A firewall, which is configured to filter ICMPv6 Echo Requests, SHOULD be configured to generate ICMPv6 Echo Replies for requests originated by Teredo clients. Ultimately, it is up to the network administrator who configures the ICMPv6 filtering in place, to decide whether to allow or block communication between Teredo clients and services protected by the firewall. Firewall SHOULD generate ICMPv6 Echo Reply even if the destination IPv6 address of ICMPv6 Echo Request is not in use. This enables Teredo to proceed and does not reveal information pertaining to the existence and liveliness of hosts located behind the firewall. It also saves the firewall from storing extra state. 3. Acknowledgements This document was created by using template-bare.xml by Elwyn Davies and xml2rfc tool. 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations Scanning for active IPv6 hosts behind a firewall is made useless by firewall replying to all ICMPv6 Echo Requests sourced from Teredo addresses. ICMPv6 Echo Reply generation MUST be rate-limited. 6. References Savolainen & Denis-Courmont Expires November 27, 2009 [Page 5] Internet-Draft ICMPv6 Echo Replies for Teredo May 2009 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. 6.2. Informative References [I-D.bagnulo-behave-nat64] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-nat64-03 (work in progress), March 2009. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. Authors' Addresses Teemu Savolainen Nokia Corporation Hermiankatu 12 D TAMPERE, FI-33720 FINLAND Email: teemu.savolainen@nokia.com Remi Denis-Courmont Nokia Corporation P.O. Box 407 NOKIA GROUP, 00045 FINLAND Phone: +358 50 487 6315 Email: remi.denis-courmont@nokia.com Savolainen & Denis-Courmont Expires November 27, 2009 [Page 6]