Internet DRAFT - draft-itojun-ipv6-tcp-to-anycast
draft-itojun-ipv6-tcp-to-anycast
Internet Engineering Task Force Jun-ichiro Itoh
INTERNET-DRAFT Research Lab, IIJ
Expires: January 16, 2002 July 16, 2001
Disconnecting TCP connection toward IPv6 anycast address
draft-itojun-ipv6-tcp-to-anycast-01.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.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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 January 16, 2002.
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 [Deering, 1998] defines ``anycast address''. Anycast
addresses have the following capabilities and restrictions [Hinden,
1998] :
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: January 16, 2002 [Page 1]
DRAFT Disconnect TCP to anycast July 2001
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 [Conta, 1998]
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: January 16, 2002 [Page 2]
DRAFT Disconnect TCP to anycast July 2001
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 [Conta, 1998] provides
a detailed discussions on this problem (see section 5 in RFC2463).
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
Deering, 1998.
S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification" in RFC2460 (December 1998). ftp://ftp.isi.edu/in-
notes/rfc2460.txt.
Itoh Expires: January 16, 2002 [Page 3]
DRAFT Disconnect TCP to anycast July 2001
Hinden, 1998.
R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in
RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt.
Conta, 1998.
A. Conta and S. Deering, "Internet Control Message Protocol (ICMPv6) for
the Internet Protocol Version 6 (IPv6) Specification" in RFC2463
(December 1998). ftp://ftp.isi.edu/in-notes/rfc2463.txt.
Change history
00 -> 01
Re-issue as we have more discussion on anycast these days.
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: January 16, 2002 [Page 4]
