idnits 2.17.1 draft-liu-6man-ident-tunnel-packet-addr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3837 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-01 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-08 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Wu 3 Internet-Draft C. Liu 4 Intended status: Standards Track Y. Cui 5 Expires: April 24, 2014 Tsinghua University 6 October 21, 2013 8 Identifying Addresses of IPv6 Tunnel Packets at Tunnel Exit-point 9 draft-liu-6man-ident-tunnel-packet-addr-00 11 Abstract 13 In the networks where IPv6 tunneling is used, it is not specific 14 about how a tunnel end-node identifies the received tunnel packets by 15 checking the destination and source addresses. when the tunnel end- 16 node is configured with multiple IPv6 addresses or multiple IPv6 17 tunnel instances, such identification is necessary. This document 18 describes the problem and defines the behavior of IPv6 tunnel end- 19 nodes about identifying tunnel packets. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 24, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Tunnel End-node Behavior . . . . . . . . . . . . . . . . . . 4 60 5.1. Acceptable Local/Remote Address Set Maintenance . . . . . 4 61 5.2. Inbound Tunnel Packet Identification . . . . . . . . . . 4 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 8.2. Informative References . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 IPv6 tunneling mechanism [RFC2473] provides support for various 72 protocols to work in IPv6-only network. But when a tunnel end-node 73 receives a tunnel packet, it is not specific about whether or not the 74 tunnel end-node should identify the tunnel packet by checking the 75 destination and source addresses in the packet. When the tunnel end- 76 node is configured with multiple IPv6 tunnel instance, it is also 77 undefined how to dispatch the received tunnel packet to each tunnel 78 instance. This document provides a solution to this problem by 79 defining the behavior of tunnel end-node on how to identify received 80 tunnel packets. 82 2. Requirements Language 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 3. Terminology 90 This document makes use of the following terms: 92 Acceptable Local Address Set: A set of one or more IPv6 addresses or 93 prefixes maintained by a tunnel 94 instance. It represents the set of 95 acceptable IPv6 destination addresses 96 in the received IPv6 tunnel packets. 98 Usually it consists of one or more 99 IPv6 addresses on local interfaces of 100 the tunnel end-node. 102 Acceptable Remote Address Set: A set of one or more IPv6 addresses or 103 prefixes maintained by a tunnel 104 instance. It represents the set of 105 acceptable IPv6 source addresses in 106 the received IPv6 tunnel packets. 108 Terminology defined in [RFC2473] is used extensively in this 109 document. 111 4. Problem Statement 113 Consider an IPv6 tunnel end-node with multiple IPv6 addresses 114 configured on its interface. One of the IPv6 addresses is chosen as 115 the tunnel entry-point node address [RFC2473]. When the tunnel end- 116 node receives an IPv6 tunnel packet with its destination address 117 other than the tunnel entry-point node address, the tunnel end-node 118 either discards it or accepts it. Section 3.3 of [RFC2473] states 119 that: 121 "Upon receiving an IPv6 packet destined to an IPv6 address of a 122 tunnel exit-point node, its IPv6 protocol layer processes the 123 tunnel headers." 125 According to this statement, the tunnel end-node ought to accept the 126 tunnel packet. However, when the destination IPv6 address is used to 127 distinguish among multiple tunnel instances running in the same 128 tunnel end-node, one tunnel packet may be passed to multiple tunnel 129 instances, and it may not be the expected result. 131 When there are multiple tunnel instances in a tunnel end-node and 132 each instance with a separated process engine, it must be decided 133 about which tunnel instance(s) to be chosen to process a received 134 IPv6 tunnel packet. As the payload of a IPv6 tunnel packet may be 135 various protocols, only 3 items may be used to identify a tunnel 136 packet: IPv6 destination address, IPv6 source address, and the 137 payload protocol type (the Next Header field in IPv6 tunnel packet). 138 The payload protocol type can be used to distinguish between an IPv4 139 -in-IPv6 tunnel and an IPv6-in-IPv6 tunnel. The IPv6 source and 140 destination address can be used to distinguish among tunnels of the 141 same protocol type. 143 There are several IPv6 transition mechanisms relies on point-to- 144 multipoint IPv6 tunnel, such as DS-Lite [RFC6333], Lightweight 4over6 145 [I-D.ietf-softwire-lw4over6], MAP-E [I-D.ietf-softwire-map], etc. In 146 these mechanisms, one tunnel instance may have multiple remote 147 tunnel-ends, each with different IPv6 unicast addresses. Thus, the 148 acceptable destination / source address of a inbound tunnel packet 149 could be multiple address. 151 5. Tunnel End-node Behavior 153 5.1. Acceptable Local/Remote Address Set Maintenance 155 An IPv6 tunnel end-node maintains an Acceptable Local Address Set in 156 each of its tunnel instance. An Acceptable Local Address Set 157 contains one or more IPv6 addresses or prefixes. The destination 158 address of an inbound IPv6 tunnel packet to be passed to a tunnel 159 instance MUST match a record in the Acceptable Local Address Set of 160 the tunnel instance. 162 An IPv6 tunnel end-node maintains an Acceptable Remote Address Set in 163 each of its tunnel instance. An Acceptable Remote Address Set 164 contains one or more IPv6 addresses or prefixes. The source address 165 of an inbound IPv6 tunnel packet to be passed to a tunnel instance 166 MUST match a record in the Acceptable Remote Address Set of the 167 tunnel instance. 169 For example, in a point-to-point IPv6 tunnel, the Acceptable Local 170 Address Set contains one IPv6 address(tunnel entry-point node address 171 [RFC2473]), and the Acceptable Remote Address Set contains one IPv6 172 address(tunnel exit-point node address [RFC2473]). In the tunnel 173 model of DS-Lite AFTR [RFC6333], the Acceptable Remote Address Set 174 may contains a IPv6 prefix ::/0, to represent that the tunnel accepts 175 tunnel packets from any B4s. 177 5.2. Inbound Tunnel Packet Identification 179 When an IPv6 tunnel end-node receives an IPv6 tunnel packet, the 180 tunnel end-node identifies the packet by comparing its IPv6 source 181 address, IPv6 destination address and protocol type (Next Header) 182 with the Acceptable Remote Address Set, Acceptable Local Address Set, 183 and protocol type of each tunnel instance running on the node. If 184 all the 3 fields match, the IPv6 tunnel packet is passed to the 185 tunnel instance. 187 If a tunnel packet matches more than one tunnel instance, it is 188 passed to each of the tunnel instances. If a tunnel packet matches 189 no tunnel instance, the tunnel end-node MUST discard the packet, and 190 SHOULD send a ICMPv6 error message to the source address of the 191 tunnel packet. ICMPv6 type is TBD. 193 6. Security Considerations 194 TBD 196 7. IANA Considerations 198 This document does not include an IANA request. 200 8. References 202 8.1. Normative References 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, March 1997. 207 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 208 IPv6 Specification", RFC 2473, December 1998. 210 8.2. Informative References 212 [I-D.ietf-softwire-lw4over6] 213 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 214 I. Farrer, "Lightweight 4over6: An Extension to the DS- 215 Lite Architecture", draft-ietf-softwire-lw4over6-01 (work 216 in progress), July 2013. 218 [I-D.ietf-softwire-map] 219 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 220 Murakami, T., and T. Taylor, "Mapping of Address and Port 221 with Encapsulation (MAP)", draft-ietf-softwire-map-08 222 (work in progress), August 2013. 224 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 225 Stack Lite Broadband Deployments Following IPv4 226 Exhaustion", RFC 6333, August 2011. 228 Authors' Addresses 230 Jianping Wu 231 Tsinghua University 232 Department of Computer Science, Tsinghua University 233 Beijing 100084 234 P.R.China 236 Phone: +86-10-6278-5983 237 Email: jianping@cernet.edu.cn 238 Cong Liu 239 Tsinghua University 240 Department of Computer Science, Tsinghua University 241 Beijing 100084 242 P.R.China 244 Phone: +86-10-6278-5822 245 Email: gnocuil@gmail.com 247 Yong Cui 248 Tsinghua University 249 Department of Computer Science, Tsinghua University 250 Beijing 100084 251 P.R.China 253 Phone: +86-10-6260-3059 254 Email: yong@csnet1.cs.tsinghua.edu.cn