Network Working Group J. Wu Internet-Draft C. Liu Intended status: Standards Track Y. Cui Expires: April 24, 2014 Tsinghua University October 21, 2013 Identifying Addresses of IPv6 Tunnel Packets at Tunnel Exit-point draft-liu-6man-ident-tunnel-packet-addr-00 Abstract In the networks where IPv6 tunneling is used, it is not specific about how a tunnel end-node identifies the received tunnel packets by checking the destination and source addresses. when the tunnel end- node is configured with multiple IPv6 addresses or multiple IPv6 tunnel instances, such identification is necessary. This document describes the problem and defines the behavior of IPv6 tunnel end- nodes about identifying tunnel packets. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 24, 2014. Copyright Notice Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Wu, et al. Expires April 24, 2014 [Page 1] Internet-Draft Identify Address of IPv6 Tunnel Packets October 2013 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 5. Tunnel End-node Behavior . . . . . . . . . . . . . . . . . . 4 5.1. Acceptable Local/Remote Address Set Maintenance . . . . . 4 5.2. Inbound Tunnel Packet Identification . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction IPv6 tunneling mechanism [RFC2473] provides support for various protocols to work in IPv6-only network. But when a tunnel end-node receives a tunnel packet, it is not specific about whether or not the tunnel end-node should identify the tunnel packet by checking the destination and source addresses in the packet. When the tunnel end- node is configured with multiple IPv6 tunnel instance, it is also undefined how to dispatch the received tunnel packet to each tunnel instance. This document provides a solution to this problem by defining the behavior of tunnel end-node on how to identify received tunnel packets. 2. 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 [RFC2119]. 3. Terminology This document makes use of the following terms: Acceptable Local Address Set: A set of one or more IPv6 addresses or prefixes maintained by a tunnel instance. It represents the set of acceptable IPv6 destination addresses in the received IPv6 tunnel packets. Wu, et al. Expires April 24, 2014 [Page 2] Internet-Draft Identify Address of IPv6 Tunnel Packets October 2013 Usually it consists of one or more IPv6 addresses on local interfaces of the tunnel end-node. Acceptable Remote Address Set: A set of one or more IPv6 addresses or prefixes maintained by a tunnel instance. It represents the set of acceptable IPv6 source addresses in the received IPv6 tunnel packets. Terminology defined in [RFC2473] is used extensively in this document. 4. Problem Statement Consider an IPv6 tunnel end-node with multiple IPv6 addresses configured on its interface. One of the IPv6 addresses is chosen as the tunnel entry-point node address [RFC2473]. When the tunnel end- node receives an IPv6 tunnel packet with its destination address other than the tunnel entry-point node address, the tunnel end-node either discards it or accepts it. Section 3.3 of [RFC2473] states that: "Upon receiving an IPv6 packet destined to an IPv6 address of a tunnel exit-point node, its IPv6 protocol layer processes the tunnel headers." According to this statement, the tunnel end-node ought to accept the tunnel packet. However, when the destination IPv6 address is used to distinguish among multiple tunnel instances running in the same tunnel end-node, one tunnel packet may be passed to multiple tunnel instances, and it may not be the expected result. When there are multiple tunnel instances in a tunnel end-node and each instance with a separated process engine, it must be decided about which tunnel instance(s) to be chosen to process a received IPv6 tunnel packet. As the payload of a IPv6 tunnel packet may be various protocols, only 3 items may be used to identify a tunnel packet: IPv6 destination address, IPv6 source address, and the payload protocol type (the Next Header field in IPv6 tunnel packet). The payload protocol type can be used to distinguish between an IPv4 -in-IPv6 tunnel and an IPv6-in-IPv6 tunnel. The IPv6 source and destination address can be used to distinguish among tunnels of the same protocol type. There are several IPv6 transition mechanisms relies on point-to- multipoint IPv6 tunnel, such as DS-Lite [RFC6333], Lightweight 4over6 [I-D.ietf-softwire-lw4over6], MAP-E [I-D.ietf-softwire-map], etc. In Wu, et al. Expires April 24, 2014 [Page 3] Internet-Draft Identify Address of IPv6 Tunnel Packets October 2013 these mechanisms, one tunnel instance may have multiple remote tunnel-ends, each with different IPv6 unicast addresses. Thus, the acceptable destination / source address of a inbound tunnel packet could be multiple address. 5. Tunnel End-node Behavior 5.1. Acceptable Local/Remote Address Set Maintenance An IPv6 tunnel end-node maintains an Acceptable Local Address Set in each of its tunnel instance. An Acceptable Local Address Set contains one or more IPv6 addresses or prefixes. The destination address of an inbound IPv6 tunnel packet to be passed to a tunnel instance MUST match a record in the Acceptable Local Address Set of the tunnel instance. An IPv6 tunnel end-node maintains an Acceptable Remote Address Set in each of its tunnel instance. An Acceptable Remote Address Set contains one or more IPv6 addresses or prefixes. The source address of an inbound IPv6 tunnel packet to be passed to a tunnel instance MUST match a record in the Acceptable Remote Address Set of the tunnel instance. For example, in a point-to-point IPv6 tunnel, the Acceptable Local Address Set contains one IPv6 address(tunnel entry-point node address [RFC2473]), and the Acceptable Remote Address Set contains one IPv6 address(tunnel exit-point node address [RFC2473]). In the tunnel model of DS-Lite AFTR [RFC6333], the Acceptable Remote Address Set may contains a IPv6 prefix ::/0, to represent that the tunnel accepts tunnel packets from any B4s. 5.2. Inbound Tunnel Packet Identification When an IPv6 tunnel end-node receives an IPv6 tunnel packet, the tunnel end-node identifies the packet by comparing its IPv6 source address, IPv6 destination address and protocol type (Next Header) with the Acceptable Remote Address Set, Acceptable Local Address Set, and protocol type of each tunnel instance running on the node. If all the 3 fields match, the IPv6 tunnel packet is passed to the tunnel instance. If a tunnel packet matches more than one tunnel instance, it is passed to each of the tunnel instances. If a tunnel packet matches no tunnel instance, the tunnel end-node MUST discard the packet, and SHOULD send a ICMPv6 error message to the source address of the tunnel packet. ICMPv6 type is TBD. 6. Security Considerations Wu, et al. Expires April 24, 2014 [Page 4] Internet-Draft Identify Address of IPv6 Tunnel Packets October 2013 TBD 7. IANA Considerations This document does not include an IANA request. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. 8.2. Informative References [I-D.ietf-softwire-lw4over6] Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS- Lite Architecture", draft-ietf-softwire-lw4over6-01 (work in progress), July 2013. [I-D.ietf-softwire-map] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP)", draft-ietf-softwire-map-08 (work in progress), August 2013. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. Authors' Addresses Jianping Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5983 Email: jianping@cernet.edu.cn Wu, et al. Expires April 24, 2014 [Page 5] Internet-Draft Identify Address of IPv6 Tunnel Packets October 2013 Cong Liu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: gnocuil@gmail.com Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6260-3059 Email: yong@csnet1.cs.tsinghua.edu.cn Wu, et al. Expires April 24, 2014 [Page 6]