idnits 2.17.1 draft-liu-6man-tunnel-mtu-config-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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 3841 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) == Unused Reference: 'RFC4443' is defined on line 184, but no explicit reference was found in the text == Unused Reference: 'RFC1191' is defined on line 196, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-08 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Cui 3 Internet-Draft C. Liu 4 Intended status: Standards Track Tsinghua University 5 Expires: April 24, 2014 October 21, 2013 7 IPv6 Tunnel MTU Configuration 8 draft-liu-6man-tunnel-mtu-config-00 10 Abstract 12 It is not specific about how to decide IPv6 tunnel MTU in IPv6 13 tunneling mechanisms in some situations. This document describes the 14 problem and provides a general solution to decide tunnel MTU value. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 24, 2014. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 52 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 54 5. Tunnel MTU Configuration . . . . . . . . . . . . . . . . . . 3 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 8.2. Informative References . . . . . . . . . . . . . . . . . 4 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 IPv6 tunneling mechanism defined in [RFC2473] provides support for 65 various protocols to work in IPv6-only network. Because IPv6 66 intermediate routers do not support fragmentation, a IPv6 tunnel 67 packet may be discarded by an intermediate router if the packet size 68 exceeds the next-hop MTU. Thus, the tunnel MTU of IPv6 tunnel nodes 69 should be well decided and managed in order to eliminate data loss. 71 But [RFC2473] is not specific about how to decide tunnel MTU, when a 72 tunnel entry-point connects to multiple tunnel exit-points. It is 73 also not clear about how to decide tunnel MTU without Path MTU 74 Discovery [RFC1981]. This document describes the problems and 75 proposes a solution to specify the behavior of tunnel entry-point to 76 configure its tunnel MTU. 78 2. Requirements Language 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 3. Terminology 86 Terminology defined in [RFC2473] is used extensively in this 87 document. 89 4. Problem Statement 91 Section 6.7 of [RFC2473] defines the behavior of the IPv6 tunnel 92 entry-point to set its tunnel MTU that: 94 "The tunnel MTU is set dynamically to the Path MTU between the 95 tunnel entry-point and the tunnel exit-point nodes, minus the size 96 of the tunnel headers" 98 "The tunnel entry-point node performs Path MTU discovery on the 99 path between the tunnel entry-point and exit-point nodes" 101 However, it is unspecific about how a tunnel entry-point sets its 102 tunnel MTU without performing Path MTU discovery. As IPv6 tunneling 103 is the foundation of several IPv6 transition mechanisms, but some of 104 these mechanisms require tunnel end-nodes not to perform Path MTU 105 discovery. DS-Lite [RFC6333] handles this by increasing the MTU size 106 of all the links in the path by at least 40 bytes. MAP-E 107 [I-D.ietf-softwire-map] strongly recommends to well manage the MTU of 108 links in the whole MAP domain, which is similar to what DS-Lite does, 109 and specifies that "A MAP BR SHOULD NOT by default use Path MTU 110 discovery across the MAP domain" in section 8.3.1 of 111 [I-D.ietf-softwire-map]. 113 In [RFC2473], tunnel MTU is defined as the Path MTU between the 114 tunnel entry-point and the tunnel exit-point nodes minus the size of 115 the tunnel header. In some cases, a single tunnel entry-point may 116 connect to multiple tunnel exit-points, e.g. the IPv6 address of the 117 tunnel exit-point is a multicast or an anycast address, or the tunnel 118 entry-point works as an AFTR element [RFC6333]. 120 Figure 1 shows an example that a tunnel entry-point is connecting to 121 2 tunnel exit-points. When the tunnel entry-point sends a tunnel 122 packet of length 1500 to tunnel exit-point1, the packet is discarded 123 by the intermediate router and the router sends an ICMPv6 "Packet Too 124 Big"(PTB) message to tunnel entry-point with the MTU field equals 125 1280. After received the ICMPv6 PTB message, the tunnel entry- point 126 sets its tunnel MTU to 1280-40=1240 according to section 6.7 of 127 [RFC2473]. After that, when the tunnel entry-point sends tunnel 128 packets to tunnel exit-point2, the tunnel packet size will be 129 restricted to 1280. This is inefficient. 131 +-------------+ +-------+ 132 MTU=1280 | IPv6 Tunnel | | IPv4 | 133 +------+ exit-point1 +--+ host2 | 134 MTU=1500 MTU=1500 | +-------------+ +-------+ 135 | | | 136 +-------+ | +-------------+ | +----+---+ +-------------+ 137 | IPv4 | v | IPv6 Tunnel | v | IPv6 | MTU=1500 | IPv6 Tunnel | 138 | host1 +-----+ entry-point +-----+ router +----------+ exit-point2 | 139 +-------+ +-------------+ +--------+ +-------------+ 141 Figure 1: An Example of IPv6 Tunneling Scenario 143 5. Tunnel MTU Configuration 144 An IPv6 tunnel entry-point node SHOULD perform Path MTU discovery 145 dynamically on the paths between the tunnel entry-point itself and 146 each exit-point node it connects to. The PMTU information SHOULD be 147 stored in a table indexed by the destination IPv6 address as is 148 described in section 5.2 of [RFC1981]. When a packet enters the 149 tunnel, the tunnel entry-point looks up the PMTU table for the 150 corresponding PMTU value. If not found, it uses the MTU of IPv6 151 next-hop link as the default value. This PMTU value minus the size 152 of the tunnel headers is set as the tunnel MTU value. 154 If the IPv6 tunnel entry-point node does not perform Path MTU 155 discovery to decide its tunnel MTU, the network operator MUST 156 estimate a safe MTU value and configure this value as the tunnel MTU. 157 This safe MTU value should be no larger than the minimum Path MTU 158 between the tunnel node and every potential tunnel exit-point, minus 159 the size of tunnel headers. If the operator can not decide this 160 value, the tunnel MTU SHOULD be set to 1280 minus the size of tunnel 161 headers. 163 6. Security Considerations 165 TBD 167 7. IANA Considerations 169 This document does not include an IANA request. 171 8. References 173 8.1. Normative References 175 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 176 for IP version 6", RFC 1981, August 1996. 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, March 1997. 181 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 182 IPv6 Specification", RFC 2473, December 1998. 184 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 185 Message Protocol (ICMPv6) for the Internet Protocol 186 Version 6 (IPv6) Specification", RFC 4443, March 2006. 188 8.2. Informative References 190 [I-D.ietf-softwire-map] 191 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 192 Murakami, T., and T. Taylor, "Mapping of Address and Port 193 with Encapsulation (MAP)", draft-ietf-softwire-map-08 194 (work in progress), August 2013. 196 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 197 November 1990. 199 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 200 Stack Lite Broadband Deployments Following IPv4 201 Exhaustion", RFC 6333, August 2011. 203 Authors' Addresses 205 Yong Cui 206 Tsinghua University 207 Department of Computer Science, Tsinghua University 208 Beijing 100084 209 P.R.China 211 Phone: +86-10-6260-3059 212 Email: yong@csnet1.cs.tsinghua.edu.cn 214 Cong Liu 215 Tsinghua University 216 Department of Computer Science, Tsinghua University 217 Beijing 100084 218 P.R.China 220 Phone: +86-10-6278-5822 221 Email: gnocuil@gmail.com