idnits 2.17.1 draft-ietf-v6ops-cidr-prefix-01.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 (February 13, 2015) is 3360 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-05 -- 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: August 17, 2015 CEA, LIST 6 F. Baker 7 Cisco Systems 8 February 13, 2015 10 IPv6 Prefix Length Recommendation for Forwarding 11 draft-ietf-v6ops-cidr-prefix-01 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 algorithms should therefore impose no rules on prefix length, but 22 implement longest-match-first on prefixes of any valid length. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 17, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 71 6.2. Informative References . . . . . . . . . . . . . . . . . 4 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 74 1. Introduction 76 Discussions on the 64-bit boundary in IPv6 addressing ([RFC7421]) 77 revealed a need for a clear recommendation on which bits must be used 78 by forwarding decision-making processes. However, such a 79 recommendation was out of scope for that document. 81 Although Section 2.5 of [RFC4291] states "IPv6 unicast addresses are 82 aggregatable with prefixes of arbitrary bit-length, similar to IPv4 83 addresses under Classless Inter-Domain Routing" (CIDR, [RFC4632]), 84 there is still a misinterpretation that IPv6 prefixes can be either 85 /127 ([RFC6164]) or any length up to /64. This (mis)interpretation 86 is mainly induced by the 64-bit boundary in IPv6 addressing. 88 As discussed in [RFC7421], "the notion of a /64 boundary in the 89 address was introduced after the initial design of IPv6, following a 90 period when it was expected to be at /80". This evolution of the 91 IPv6 Addressing architecture, resulting in [RFC4291], and followed 92 with the addition of /127 prefixes for point-to-point links, clearly 93 demonstrates the intent for future IPv6 developments to have the 94 flexibility to change this part of the architecture when justified. 96 It is fundamental to not link routing and forwarding to the IPv6 97 prefix/address semantics [RFC4291]. This document includes a 98 recommendation for that aim. 100 Forwarding decisions rely on the longest-match-first algorithm, which 101 stipulates that, given a choice between two prefixes in the 102 Forwarding Information Base (FIB) of different length that match the 103 destination address in each bit up to their respective lengths, the 104 longer prefix is used. This document's recommendation (Section 2) is 105 that IPv6 forwarding must follow the longest-match-first rule, 106 regardless of prefix length, barring the configuration of some 107 overriding policy. 109 This recommendation does not conflict with the 64-bit boundary for 110 some IPv6 stateless address autoconfiguration (SLAAC, [RFC4862]) 111 based schemes such as [RFC2464]. Indeed, [RFC7421] clarifies this is 112 only a parameter in the SLAAC process and other longer prefix lengths 113 are in operational use (e.g., either manually configured or based 114 upon DHCPv6 [RFC3315]). 116 A historical reminder of CIDR is documented in [RFC1380] and 117 Section 2 of [RFC4632]. 119 2. Recommendation 121 IPv6 implementations MUST conform to the rules specified in 122 Section 5.1 of [RFC4632]. 124 Forwarding decision-making processes MUST NOT restrict the length of 125 IPv6 prefixes by design. In particular, forwarding processes MUST be 126 designed to process prefixes of any length up to /128, by increments 127 of 1. 129 Obviously, policies can be enforced to restrict the length of IP 130 prefixes advertised within a given domain or in a given 131 interconnection link. These policies are deployment-specific and/or 132 driven by administrative (interconnection) considerations. 134 3. IANA Considerations 136 This document does not require any action from IANA. 138 4. Security Considerations 140 This document does not introduce security issues in addition to what 141 is discussed in [RFC4291]. 143 IPv6 security issues, including operational ones, are discussed in 144 [RFC4942] and [I-D.ietf-opsec-v6]. 146 5. Acknowledgements 148 Thanks to Eric Vyncke, Christian Jacquenet, Brian Carpenter, Fernando 149 Gont, Tatuya Jinmei, Lorenzo Colitti, Ross Chandler, and David Farmer 150 for their contributions and comments. 152 Special thanks to Randy Bush for his support. 154 6. References 156 6.1. Normative References 158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 159 Requirement Levels", BCP 14, RFC 2119, March 1997. 161 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 162 Architecture", RFC 4291, February 2006. 164 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 165 (CIDR): The Internet Address Assignment and Aggregation 166 Plan", BCP 122, RFC 4632, August 2006. 168 6.2. Informative References 170 [I-D.ietf-opsec-v6] 171 Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational 172 Security Considerations for IPv6 Networks", draft-ietf- 173 opsec-v6-05 (work in progress), October 2014. 175 [RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing 176 and Addressing", RFC 1380, November 1992. 178 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 179 Networks", RFC 2464, December 1998. 181 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 182 and M. Carney, "Dynamic Host Configuration Protocol for 183 IPv6 (DHCPv6)", RFC 3315, July 2003. 185 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 186 Address Autoconfiguration", RFC 4862, September 2007. 188 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 189 Co-existence Security Considerations", RFC 4942, September 190 2007. 192 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 193 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 194 Router Links", RFC 6164, April 2011. 196 [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, 197 A., and A. Yourtchenko, "Analysis of the 64-bit Boundary 198 in IPv6 Addressing", RFC 7421, January 2015. 200 Authors' Addresses 202 Mohamed Boucadair 203 France Telecom 204 Rennes 35000 205 France 207 Email: mohamed.boucadair@orange.com 209 Alexandre Petrescu 210 CEA, LIST 211 CEA Saclay 212 Gif-sur-Yvette, Ile-de-France 91190 213 France 215 Phone: +33169089223 216 Email: alexandre.petrescu@cea.fr 218 Fred Baker 219 Cisco Systems 220 Santa Barbara, California 93117 221 USA 223 Email: fred@cisco.com