idnits 2.17.1 draft-ietf-v6ops-cidr-prefix-02.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 (April 20, 2015) is 3293 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-27) exists of draft-ietf-opsec-v6-06 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Best Current Practice A. Petrescu 5 Expires: October 22, 2015 CEA, LIST 6 F. Baker 7 Cisco Systems 8 April 20, 2015 10 IPv6 Prefix Length Recommendation for Forwarding 11 draft-ietf-v6ops-cidr-prefix-02 13 Abstract 15 IPv6 prefix length, as in IPv4, is a parameter conveyed and used in 16 IPv6 routing and forwarding processes in accordance with the 17 Classless Inter-domain Routing (CIDR) architecture. The length of an 18 IPv6 prefix may be any number from zero to 128, although subnets 19 using stateless address autoconfiguration (SLAAC) for address 20 allocation conventionally use a /64 prefix. Hardware and software 21 implementations of routing and forwarding should therefore impose no 22 rules on prefix length, but implement longest-match-first on prefixes 23 of any valid length. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 22, 2015. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 72 6.2. Informative References . . . . . . . . . . . . . . . . . 4 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 75 1. Introduction 77 Discussions on the 64-bit boundary in IPv6 addressing ([RFC7421]) 78 revealed a need for a clear recommendation on which bits must be used 79 by forwarding decision-making processes. However, such a 80 recommendation was out of scope for that document. 82 Although Section 2.5 of [RFC4291] states "IPv6 unicast addresses are 83 aggregatable with prefixes of arbitrary bit-length, similar to IPv4 84 addresses under Classless Inter-Domain Routing" (CIDR, [RFC4632]), 85 there is still a misinterpretation that IPv6 prefixes can be either 86 /127 ([RFC6164]) or any length up to /64. This (mis)interpretation 87 is mainly induced by the 64-bit boundary in IPv6 addressing. 89 As discussed in [RFC7421], "the notion of a /64 boundary in the 90 address was introduced after the initial design of IPv6, following a 91 period when it was expected to be at /80". This evolution of the 92 IPv6 Addressing architecture, resulting in [RFC4291], and followed 93 with the addition of /127 prefixes for point-to-point links, clearly 94 demonstrates the intent for future IPv6 developments to have the 95 flexibility to change this part of the architecture when justified. 97 It is fundamental to not link routing and forwarding to the IPv6 98 prefix/address semantics [RFC4291]. This document includes a 99 recommendation for that aim. 101 Forwarding decisions rely on the longest-match-first algorithm, which 102 stipulates that, given a choice between two prefixes in the 103 Forwarding Information Base (FIB) of different length that match the 104 destination address in each bit up to their respective lengths, the 105 longer prefix is used. This document's recommendation (Section 2) is 106 that IPv6 forwarding must follow the longest-match-first rule, 107 regardless of prefix length, barring the configuration of some 108 overriding policy. 110 This recommendation does not conflict with the 64-bit boundary for 111 some IPv6 stateless address autoconfiguration (SLAAC, [RFC4862]) 112 based schemes such as [RFC2464]. Indeed, [RFC7421] clarifies this is 113 only a parameter in the SLAAC process and other longer prefix lengths 114 are in operational use (e.g., either manually configured or based 115 upon DHCPv6 [RFC3315]). 117 A historical reminder of CIDR is documented in [RFC1380] and 118 Section 2 of [RFC4632]. 120 2. Recommendation 122 IPv6 implementations MUST conform to the rules specified in 123 Section 5.1 of [RFC4632]. 125 Forwarding decision-making processes MUST NOT restrict the length of 126 IPv6 prefixes by design. In particular, forwarding processes MUST be 127 designed to process prefixes of any length up to /128, by increments 128 of 1. 130 Obviously, policies can be enforced to restrict the length of IP 131 prefixes advertised within a given domain or in a given 132 interconnection link. These policies are deployment-specific and/or 133 driven by administrative (interconnection) considerations. 135 3. IANA Considerations 137 This document does not require any action from IANA. 139 4. Security Considerations 141 This document does not introduce security issues in addition to what 142 is discussed in [RFC4291]. 144 IPv6 security issues, including operational ones, are discussed in 145 [RFC4942] and [I-D.ietf-opsec-v6]. 147 5. Acknowledgements 149 Thanks to Eric Vyncke, Christian Jacquenet, Brian Carpenter, Fernando 150 Gont, Tatuya Jinmei, Lorenzo Colitti, Ross Chandler, David Farmer, 151 and David Black for their contributions and comments. 153 Special thanks to Randy Bush for his support. 155 6. References 157 6.1. Normative References 159 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 160 Requirement Levels", BCP 14, RFC 2119, March 1997. 162 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 163 Architecture", RFC 4291, February 2006. 165 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 166 (CIDR): The Internet Address Assignment and Aggregation 167 Plan", BCP 122, RFC 4632, August 2006. 169 6.2. Informative References 171 [I-D.ietf-opsec-v6] 172 Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational 173 Security Considerations for IPv6 Networks", draft-ietf- 174 opsec-v6-06 (work in progress), March 2015. 176 [RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing 177 and Addressing", RFC 1380, November 1992. 179 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 180 Networks", RFC 2464, December 1998. 182 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 183 and M. Carney, "Dynamic Host Configuration Protocol for 184 IPv6 (DHCPv6)", RFC 3315, July 2003. 186 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 187 Address Autoconfiguration", RFC 4862, September 2007. 189 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 190 Co-existence Security Considerations", RFC 4942, September 191 2007. 193 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 194 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 195 Router Links", RFC 6164, April 2011. 197 [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, 198 A., and A. Yourtchenko, "Analysis of the 64-bit Boundary 199 in IPv6 Addressing", RFC 7421, January 2015. 201 Authors' Addresses 203 Mohamed Boucadair 204 France Telecom 205 Rennes 35000 206 France 208 Email: mohamed.boucadair@orange.com 210 Alexandre Petrescu 211 CEA, LIST 212 CEA Saclay 213 Gif-sur-Yvette, Ile-de-France 91190 214 France 216 Phone: +33169089223 217 Email: alexandre.petrescu@cea.fr 219 Fred Baker 220 Cisco Systems 221 Santa Barbara, California 93117 222 USA 224 Email: fred@cisco.com