Internet Engineering Task Force Jun-ichiro Itoh INTERNET-DRAFT Research Lab, IIJ Expires: April 9, 1999 October 9, 1998 Disconnecting TCP connection toward IPv6 anycast address draft-itojun-ipv6-tcp-to-anycast-00.txt Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be April 9, 1999. Abstract IPv6 specification implicitly disallows TCP connection toward IPv6 anycast address. However, if such a connection request happens by mistake, currently there is no way to report the incident to the originator of the TCP connection. The document tries to define a way to disconnect TCP connections made toward IPv6 anycast addresses. 1. Problem IPv6 specification [Hinden, 1995] defines ``anycast address''. Anycast addresses have the following capabilities and restrictions: o Anycast address is not distinguishable from non-anycast, unicast addresses. o Anycast address can be assigned to multiple interfaces of multiple nodes. o Anycast address MUST NOT be assigned to an IPv6 host. It can be assigned to an IPv6 router only. Itoh Expires: April 9, 1999 [Page 1] DRAFT Disconnect TCP to anycast October 1998 o Anycast address MUST NOT be used in source address field in IPv6 header. Since anycast address MUST NOT be used as IPv6 source address, TCP connection using anycast address MUST NOT be established. However, since anycast address is indistinguishable from (non-anycast) unicast addresses, a TCP connection is sometimes requested toward an anycast address, and in the TCP scheme there is no way to report the error. Consider the following scenario: o We have Host A and router B on the network. The topology between host A and router B has no effect to the following scenario, so we assume they share the same network medium. o An IPv6 anycast address, 3ffe:0501::1, is assigned to an interface of router B. ==+== 3ffe:0502::/64 | 3ffe:0502::B' | host A router B | | 3ffe:0501::B | 3ffe:0501::A | 3ffe:0501::1 anycast ==+===============================+== 3ffe:0501::/64 ----------------------> SYN to 3ffe:0501::1 port X <---------------------- what kind of error report is suitable? Since an anycast address is indistinguishable from non-anycast addresses, host A may transmit TCP connection request toward IPv6 address 3ffe:0501::1, port X. The standard behavior for TCP stack on router B is to transmit toward host A a TCP packet, with RST bit set to disconnect the TCP connection. However, in this situation router B cannot transmit TCP RST packet toward host A, since router B needs to put its anycast address, 3ffe:0501::1, into source address field in IPv6 header to do this. A non-active way of dealing with this problem is, silently ignore the TCP connection request from host A to router B, and wait for host A to timeout. This is not a desired behavior. 2. Solution If a router gets TCP connection request (SYN packet) toward one of its anycast addresses, the router SHOULD transmit an ICMPv6 [Deering, 1995] error packet, with type field 1 (destination unreachable), code field 3 (address unreachable). Source address field of IPv6 header will be filled by an IPv6 (non-anycast) unicast address assigned to the router. Itoh Expires: April 9, 1999 [Page 2] DRAFT Disconnect TCP to anycast October 1998 In the example illustrated in Problem section, router B SHOULD transmit an ICMPv6 error packet toward host A. The source address field of IPv6 header for the ICMPv6 packet will be 3ffe:0501::B. Implementation note: If the originating host of the TCP connection is a BSD-based implementation, it will count the number of ICMPv6 error packets in tcp_notify(). If the number of ICMPv6 error packets exceeds the limit, the originating host drops the TCP connection. In this case, TCP connection can be disconnected much quicker. The proposed method MUST be removed when one of the following events happens in the future: o Restriction imposed on IPv6 anycast address is loosened, so that anycast address can be placed into source address field of the IPv6 header, or o TCP-over-IPv6 is modified to provide some way to accept a connection toward IPv6 anycast address. 3. Alternative solutions We can try to define some DNS resource record to denote if an IPv6 unicast address is anycast address, or non-anycast address. However, it looks to be very hard to deploy. Also, we must have a way to disconnect TCP connection request toward anycast address, anyway. 4. Security considerations The document only clarifies the use of TCP-over-IPv6 and ICMPv6, and the author believes that the draft raises no new security problem. Malicious intermediate router can transmit forged ICMPv6 error report packet, to prevent two hosts from establishing TCP connection. This is known problem in ICMPv6, and ICMPv6 specification [Deering, 1995] provides a detailed discussions on this problem (see section 5 in RFC1885). ICMPv6 address unreachable packet provides a way to report an error in per-address, not per-TCP-port, basis. Therefore, some implementation may lose all connections toward the reported address, not the specific connection that caused the ICMPv6 error report. This is not a problem for this draft, because no TCP connection toward IPv6 anycast address is allowed at this moment. References Hinden, 1995. S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification" in RFC1883 (December 1995). ftp://ftp.isi.edu/in- notes/rfc1883.txt. Itoh Expires: April 9, 1999 [Page 3] DRAFT Disconnect TCP to anycast October 1998 Deering, 1995. A. Conta and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" in RFC1885 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1885.txt. Author's address Jun-ichiro Itoh Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku,Tokyo 101-0054, JAPAN Tel: +81-3-5259-6350 Fax: +81-3-5259-6351 email: itojun@iijlab.net Itoh Expires: April 9, 1999 [Page 4]