idnits 2.17.1 draft-ietf-v6ops-cidr-prefix-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 (January 18, 2015) is 3378 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: July 22, 2015 CEA, LIST 6 F. Baker 7 Cisco Systems 8 January 18, 2015 10 IPv6 Prefix Length Recommendation for Forwarding 11 draft-ietf-v6ops-cidr-prefix-00 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 July 22, 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 . . . . . . . . . . . . . . . . . . . . . . 3 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 71 6.2. Informative References . . . . . . . . . . . . . . . . . 4 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 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. 80 Although Section 2.5 of [RFC4291] states "IPv6 unicast addresses are 81 aggregatable with prefixes of arbitrary bit-length, similar to IPv4 82 addresses under Classless Inter-Domain Routing" (CIDR, [RFC4632]), 83 there is still a misinterpretation that IPv6 prefixes can be either 84 /127 or any length up to /64. This (mis)interpretation is mainly 85 induced by the 64-bit boundary in IPv6 addressing. 87 A detailed analysis of the 64-bit boundary in IPv6 addressing 88 together with the implication for end-site prefix assignment are 89 documented in [RFC7421], but no recommendation is included in that 90 document. 92 It is fundamental to not link routing and forwarding to the IPv6 93 prefix/address semantics [RFC4291]. This document includes a 94 recommendation for that aim. 96 Forwarding decisions rely on the longest-match-first algorithm, which 97 stipulates that, given a choice between two prefixes in the 98 Forwarding Information Base (FIB) of different length that match the 99 destination address in each bit up to their respective lengths, the 100 longer prefix is used. This document's recommendation is that IPv6 101 forwarding must follow the longest-match-first rule, regardless of 102 prefix length, barring the configuration of some overriding policy. 104 A historical reminder of CIDR is documented in [RFC1380] and 105 Section 2 of [RFC4632]. 107 2. Recommendation 109 IPv6 MUST conform to the rules specified in Section 5.1 of [RFC4632]. 111 Forwarding decision-making processes MUST NOT restrict the length of 112 IPv6 prefixes by design. In particular, forwarding processes MUST be 113 designed to process prefixes of any length up to /128, by increments 114 of 1. 116 Obviously, policies can be enforced to restrict the length of IP 117 prefixes advertised within a given domain or in a given 118 interconnection link. These policies are deployment-specific and/or 119 driven by administrative (interconnection) considerations. 121 This recommendation does not conflict with the 64-bit boundary for 122 some IPv6 stateless address autoconfiguration (SLAAC, [RFC4862]) 123 based schemes such as [RFC2464]. 125 3. IANA Considerations 127 This document does not require any action from IANA. 129 4. Security Considerations 131 This document does not introduce security issues in addition to what 132 is discussed in [RFC4291]. 134 5. Acknowledgements 136 Thanks to Eric Vyncke, Christian Jacquenet, Brian Carpenter, Fernando 137 Gont, Tatuya Jinmei, Lorenzo Colitti, and Ross Chandler for their 138 comments. 140 Special thanks to Randy Bush for his support. 142 6. References 144 6.1. Normative References 146 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 147 Requirement Levels", BCP 14, RFC 2119, March 1997. 149 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 150 Architecture", RFC 4291, February 2006. 152 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 153 (CIDR): The Internet Address Assignment and Aggregation 154 Plan", BCP 122, RFC 4632, August 2006. 156 6.2. Informative References 158 [RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing 159 and Addressing", RFC 1380, November 1992. 161 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 162 Networks", RFC 2464, December 1998. 164 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 165 Address Autoconfiguration", RFC 4862, September 2007. 167 [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, 168 A., and A. Yourtchenko, "Analysis of the 64-bit Boundary 169 in IPv6 Addressing", RFC 7421, January 2015. 171 Authors' Addresses 173 Mohamed Boucadair 174 France Telecom 175 Rennes 35000 176 France 178 Email: mohamed.boucadair@orange.com 180 Alexandre Petrescu 181 CEA, LIST 182 CEA Saclay 183 Gif-sur-Yvette, Ile-de-France 91190 184 France 186 Phone: +33169089223 187 Email: alexandre.petrescu@cea.fr 188 Fred Baker 189 Cisco Systems 190 Santa Barbara, California 93117 191 USA 193 Email: fred@cisco.com