idnits 2.17.1 draft-lubashev-ipv6-addr-mask-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 (October 27, 2017) is 2372 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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 IPv6 Operations I. Lubashev 3 Internet-Draft E. Nygren 4 Intended status: Informational Akamai Technologies 5 Expires: April 30, 2018 October 27, 2017 7 A Recommendation for IPv6 Address/Mask Notation 8 draft-lubashev-ipv6-addr-mask-01 10 Abstract 12 Since network operators are commonly assigned at least /48 IPv6 13 address prefixes, the operators and standards occasionally find 14 opportunities to devise addressing schemes that further assign 15 operational semantics to less significant bit ranges. There is 16 currently no standard or interoperable textual representation of 17 addresses sharing bit patterns that are not prefixes. This RFC 18 introduces IPv6 Address/Mask notation that allows one to represent 19 address groupings beyond "all addresses that share a single prefix". 20 The representation is similar to the IPv4 address/mask notation in 21 its expressiveness, but it is derived from the familiar address/ 22 prefix-length notation for clarity and compatibility with existing 23 parsers. 25 For example, using this representation, both 2001:db8::/32 and 26 2001:db8:://ffff:ffff:: have the same meaning. However, a group of 27 addresses having the first 32 bits "2001:0db8::" and the last 16 bits 28 "::1234" requires the new representation: 29 2001:db8::1234//ffff:ffff::ffff or, equivalently, 30 2001:db8::1234//32+::ffff. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 30, 2018. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Netmask and Prefix-Length Notations . . . . . . . . . . . 3 68 2. Problem Description . . . . . . . . . . . . . . . . . . . . . 4 69 3. Notational Conventions . . . . . . . . . . . . . . . . . . . 5 70 4. IPv6 Address/Mask Textual Representation . . . . . . . . . . 5 71 4.1. Constraints and Validation . . . . . . . . . . . . . . . 5 72 4.2. Examples: groups of addresses . . . . . . . . . . . . . . 5 73 4.3. Examples: specific addresses and groups to which they 74 belong . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.4. Textual representation of the Address and Mask . . . . . 6 76 4.5. Use prefix length instead of mask . . . . . . . . . . . . 6 77 5. Scoped Mask/Value notation . . . . . . . . . . . . . . . . . 6 78 6. Compatibility and Parser guidelines . . . . . . . . . . . . . 7 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 80 8. Address Utilization Considerations . . . . . . . . . . . . . 8 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 82 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 10.1. Since draft-lubashev-ipv6-addr-mask-00 . . . . . . . . . 8 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 87 12.2. Informative References . . . . . . . . . . . . . . . . . 9 88 Appendix A. Examples of Semantic Use of Lower Address Bits . . . 11 89 A.1. A Framework for Semantic IPv6 Prefix and Gap Analysis . . 11 90 A.2. Teredo . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 A.3. OpenFlow Switch Configuration . . . . . . . . . . . . . . 11 92 A.4. TeraStream IPv6 Addressing . . . . . . . . . . . . . . . 11 93 A.5. SURFnet IPv6 Address Plan and Incognito Routing Plan . . 11 94 A.6. Geolocation-based addressing method for IPv6 addresses . 12 95 A.7. Customer IDs in less significant bits . . . . . . . . . . 12 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 98 1. Introduction 100 We have learned to think of IPv4 address groupings in terms of CIDR 101 blocks, because virtually all logical address groupings fit that 102 model well: IP address allocations, subnets, routing announcements, 103 etc. 105 With the move to IPv6, the primary mechanism for address grouping 106 remains matching by prefix length, albeit with longer prefix lengths. 107 This only allows for strictly hierarchical address groupings. The 108 longer address lengths, however, provide opportunities for assigning 109 operator-specific semantics to bit strings within addresses beyond 110 the prefix, especially when allocating addresses for virtual 111 services. 113 Numerous systems (see Appendix A for examples) have been assigning 114 semantics to IPv6 bits that come after IANA prefix bits. Developers 115 of these systems attempted to communicate address patterns underlying 116 their system semantics both in documentation and in machine-readable 117 configurations accompanying the systems. Due to the lack of a 118 standard textual representation, the documentation often resorted to 119 pictographs and verbose English descriptions. The configuration 120 syntax and parsers were invariably ad hoc and incompatible with other 121 systems. 123 Here we define a syntax for representing groupings (matching rules) 124 of IPv6 addresses, where a set of less significant bits have a 125 particular value. For example, 2001:db8::1234//ffff:ffff::ffff 126 matches all addresses whose 32 most significant bits are 2001:0db8 127 and whose 16 least significant bits are 1234. 129 This document only concerns itself with the textual representation of 130 address groups that cannot be expressed as CIDR blocks. Our goal is 131 standardizing on a consistent representation to remove a hindrance to 132 interoperability of systems that wish to express rules and policies 133 that apply to such address groups (see Appendix A for examples). 134 Guidance for the applicability of such address groupings is outside 135 the scope of this document. 137 1.1. Netmask and Prefix-Length Notations 139 There are two common textual representations for identifying groups 140 of addresses (networks, subnets, internet routing blocks). These 141 representations can also be used to identify an individual address 142 and its subnet. 144 The netmask notation described by [RFC0950] is commonly used for 145 IPv4. It consists of a tuple of a network address and a network 146 mask. For example: 198.51.100.4 netmask 255.255.255.0. 148 The address/prefix-length notation described by [RFC4632] is commonly 149 used for both IPv4 and IPv6. It consists of a tuple of a network 150 address and a prefix length. For example: 198.51.100.4/24 or 151 2001:db8::1234/32. 153 Depending on the context, netmask and prefix length notations can 154 specify either a "group of addresses" or "an individual address and a 155 group of addresses to which it belongs". If the network address 156 contains one or more set bits not selected by the network mask or 157 prefix length, then network address specifies an individual address 158 in addition to the subnet. For example: 198.51.100.4/24 means 159 "address 198.51.100.4 within a group of addresses 198.51.100.0 - 160 198.51.100.255". 162 2. Problem Description 164 The problem with the prefix length notation for IPv6 is that it is 165 not sufficiently expressive of IPv6 address groupings for a growing 166 number of applications. 168 IPv6 address allocation guidelines [RFC6177] guarantee at least a /48 169 allocation to network operators and strongly recommend a multi-/64 170 allocation to end sites. Because these address blocks are orders of 171 magnitude larger than any imaginable number of physical hosts, 172 network operators are managing those addresses in new and creative 173 ways. 175 Sometimes, useful address grouping are not "all addresses that share 176 a prefix of a certain length". Additionally, within an 177 administrative scope, there are use-cases where semantics are 178 assigned to individual bit ranges. 180 Consider these examples: 182 1. Allocating a block of addresses to each host and using the least 183 significant bits to indicate a TLS certificate. These operators 184 may need a way to express a rule that applies to all traffic that 185 uses a particular TLS certificate. 187 2. Network operators managing multiple similar data centers may have 188 different prefixes routed to those data centers but desire a 189 unified set of rules for assigning, managing, and routing IPv6 190 addresses within those data centers. These operators need to 191 express rules that do not depend on the prefixes of the addresses 192 to which the rules apply. 194 3. Notational Conventions 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in [RFC2119]. 200 4. IPv6 Address/Mask Textual Representation 202 This RFC extends address/prefix-length notation of [RFC4632] in a way 203 that is reminiscent of the IPv4 netmask notation of [RFC0950]. The 204 address/mask notation allows specifying IPv6 mask instead of the 205 prefix length. 207 The address/mask notation is defined as: 209 ADDRESS // MASK 211 Both ADDRESS and MASK are IPv6 addresses. The MASK indicates which 212 bits of the ADDRESS are relevant for the address grouping. Note that 213 the MASK may be sparse and is not strictly a prefix. For example: 214 2001:db8::1234//ffff:ffff::ffff. 216 The "//" was chosen as a separator for address/mask notation, since 217 it is similar to the "/" separator used by address/prefix-length (and 218 hence is readily recognizable) but prevents incorrectly parsing 219 address/mask as address/prefix-length. 221 4.1. Constraints and Validation 223 To be a valid definition for just a group of addresses, the ADDRESS 224 part MUST NOT have any bits set outside of the MASK. Otherwise, the 225 ADDRESS // MASK represents an individual address and a group of 226 addresses it belongs to. 228 4.2. Examples: groups of addresses 230 1. 2001:db8::1234//ffff:ffff::ffff 232 This specifies IPv6 addresses that look like 2001:db8::1234 when 233 you ignore bits 16-95. 235 2. ::aa00:1234//::ff00:ffff 237 This specifies IPv6 addresses that have "aa" in bits 24-31 and 238 "1234" in bits 0-15. 240 3. 2001:db8:://ffff:ffff:: 242 This is equivalent to 2001:db8::/32. 244 4.3. Examples: specific addresses and groups to which they belong 246 1. 2001:db8::1:1234//ffff:ffff::ffff 248 This specifies IPv6 address 2001:db8::1:1234 that belongs to a 249 group of addresses that look like 2001:db8::1234 when you ignore 250 bits 16-95. 252 2. 2001:db8::aa00:1234//::ff00:ffff 254 This specifies IPv6 address 2001:db8::aa00:1234 that belongs to a 255 group of addresses that have "aa" in bits 24-31 and "1234" in 256 bits 0-15. 258 3. 2001:db8::1//ffff:ffff:: 260 This is equivalent to 2001:db8::1/32. 262 4.4. Textual representation of the Address and Mask 264 When IPv6 mask is used after "//", both the network address and mask 265 parts MUST be formatted as IPv6 addresses and, therefore, their 266 canonical textual representation is dictated by [RFC5952]. 268 4.5. Use prefix length instead of mask 270 The canonical representation of a group of IPv6 addresses MUST use a 271 prefix length instead of a mask if possible. That is, if the mask 272 has all its most significant bits set, up to some bit, followed by 273 all clear bits, then the canonical representation MUST use a prefix 274 length. 276 5. Scoped Mask/Value notation 278 Since assigning operator-specific semantics to bit ranges is only 279 possible within the address space assigned to the operator by IANA, a 280 common use-case is to specify an address/mask within an IANA-assigned 281 prefix scope. For example, all addresses ending with ::1234 within 282 2001:db8::/32 can be specified as 2001:db8::1234//ffff:ffff::ffff. 284 To make these representations easier to manage and validate, it helps 285 to have an explicit convention for representing prefixes within 286 address groups. For example, 2001:db8::1234//ffff:ffff::ffff can be 287 represented as 2001:db8::1234//32+::ffff. 289 This is specified as: 291 ADDRESS // PFX_LEN + SCOPED_MASK 293 Scoped Mask/Value notation representation can be canonicalized using 294 a ADDRESS // MASK notation. The canonical MASK is constructed by 295 performing the bitwise-or of SCOPED_MASK and the mask derived from an 296 address with the PFX_LEN most significant bits set. 298 The PFX_LEN most significant bits MUST NOT be set in SCOPED_MASK. 300 6. Compatibility and Parser guidelines 302 Only parsers that wish to support address groupings that cannot be 303 represented using address/prefix-length are required to support 304 address/mask notation. 306 Systems that support communicating address grouping in address/mask 307 notation to other systems SHOULD communicate such grouping in 308 canonical address/prefix-length notation, if possible. This ensures 309 compatibility with systems that do not support address/mask notation, 310 if all configured address groupings are proper CIDR prefixes. 312 Address groupings that cannot be expressed using address/prefix- 313 length notation MAY be communicated using Scoped Mask/Value 314 (Section 5) notation, as long as the PFX_LEN (semantic prefix scope) 315 has been configured via external means (i.e. PFX_LEN SHOULD NOT be 316 automatically derived from the MASK bitmap by the system itself). 318 7. Security Considerations 320 This document only defines textual representation for IPv6 address 321 groupings. It does not intend to recommend when assigning semantics 322 to specific bit ranges and matching based on bit substrings is 323 applicable or appropriate. 325 IP addresses can be spoofed or attacker-controlled. This is 326 especially true of IPv6 addresses differing only in less significant 327 bits and belonging to different administrative domains. When used in 328 policies applied to incoming traffic, the MASK part of the address/ 329 mask notation SHOULD have as many set bits as the semantics of the 330 policy would allow. 332 Operators wishing to assign semantics to bit ranges should be aware 333 that these semantics may be guessable or leaked outside the 334 organization. Hence, there is a risk of privacy/information leakage. 336 8. Address Utilization Considerations 338 Since IPv6 allocation guidelines [RFC6177] guarantee at least a /48 339 allocation to network operators, it would be an enormous waste of the 340 address space to assign IPv6 addresses only to physical hosts or 341 network interfaces. 343 On the other hand, a gratuitous use of lower address bits can lead to 344 a premature address space exhaustion and difficulties in adapting to 345 the future needs of the organization within the assigned address 346 space. An example of such gratuitous use is designating large parts 347 of the address space for a bitmask, where only a small fraction of 348 all possible bit combinations is utilized. 350 9. IANA Considerations 352 This document has no actions for IANA. 354 10. Change Log 356 10.1. Since draft-lubashev-ipv6-addr-mask-00 358 - Changed separator from "/" to "//" 360 - Addressed privacy in Section 7 362 - Added Section 6 364 - Added Section 8 366 - Added Appendix A 368 11. Acknowledgments 370 The Acknowledgments will come here. 372 12. References 374 12.1. Normative References 376 [RFC0950] Mogul, J. and J. Postel, "Internet Standard Subnetting 377 Procedure", STD 5, RFC 950, DOI 10.17487/RFC0950, August 378 1985, . 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, 382 DOI 10.17487/RFC2119, March 1997, 383 . 385 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 386 (CIDR): The Internet Address Assignment and Aggregation 387 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 388 2006, . 390 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 391 Address Text Representation", RFC 5952, 392 DOI 10.17487/RFC5952, August 2010, 393 . 395 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 396 Assignment to End Sites", BCP 157, RFC 6177, 397 DOI 10.17487/RFC6177, March 2011, 398 . 400 12.2. Informative References 402 [GeoAddressPatent] 403 Chen, L., Steenstra, J., and K. Taylor, "US 7929535: 404 Geolocation-based addressing method for IPv6 addresses", 405 April 2011, . 408 [I-D.jiang-semantic-prefix] 409 Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang, 410 "Analysis of Semantic Embedded IPv6 Address Schemas", 411 draft-jiang-semantic-prefix-06 (work in progress), July 412 2013. 414 [IncognitoRoutingPlan] 415 Kostur, A., "How to Plan Routing for IPv6", July 2015, 416 . 419 [OpenFlow] 420 Open Networking Foundation, "OpenFlow Switch 421 Specification, Version 1.2", December 2011, 422 . 425 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 426 Network Address Translations (NATs)", RFC 4380, 427 DOI 10.17487/RFC4380, February 2006, 428 . 430 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 431 Extensions: Extension Definitions", RFC 6066, 432 DOI 10.17487/RFC6066, January 2011, 433 . 435 [SURFnetAddrPlan] 436 SURFnet, "Preparing an IPv6 Address Plan", September 2013, 437 . 440 [TeraStream] 441 Lothberg, P. and M. Abrahamsson, "TeraStream - IPv6 442 Addressing Format", October 2013, 443 . 445 Appendix A. Examples of Semantic Use of Lower Address Bits 447 Assigning semantics to lower bits of IPv6 addresses and defining 448 policies based on such address groupings have been done for many 449 years. Documents describing such policies and configurations for 450 equipment implementing these policies do not use a consistent 451 notation. Most documents resort to pictographs and verbose English, 452 while the configuration syntax and parsers are invariably ad hoc. 454 A.1. A Framework for Semantic IPv6 Prefix and Gap Analysis 456 Internet draft [I-D.jiang-semantic-prefix] describes the need for 457 adding semantics to lower IPv6 address bits to define address groups 458 that cannot be expressed as CIDR blocks and analyzes some 459 implications of this practice. This draft describes uses of such 460 address groups for creating routing policies as well as configuring 461 such policies on hosts and routers both statically and dynamically. 463 A.2. Teredo 465 Teredo protocol [RFC4380] uses four bit ranges past Teredo IANA 466 prefix bits to encode server and client IPv4 addresses, a flags 467 bitmap, and a port (section "4. Teredo Addresses"). 469 A.3. OpenFlow Switch Configuration 471 OpenFlow Switch Specification [OpenFlow] describes OpenFlow switch 472 configuration API that can match flows based on an arbitrary IPv6 473 bitmask applied to IPv6 source (OXM_OF_IPV6_SRC) or destination 474 (OXM_OF_IPV6_DST) addresses. Version 1.2 was the first version to 475 introduce such IPv6 address/bitmask flow match rules (chapter 476 A.2.3.7) in 2011. 478 A.4. TeraStream IPv6 Addressing 480 TeraStream [TeraStream] system is using bit ranges to encode service 481 type in IPv6 address bits that come after IANA prefix bits. The 482 system was launched in 2012. 484 A.5. SURFnet IPv6 Address Plan and Incognito Routing Plan 486 SURFnet published a white paper [SURFnetAddrPlan] advocating that 487 ISPs use bit ranges past their IANA prefix to encode geo-location and 488 address use types. The white paper is giving examples of a sample 489 address allocation that uses one nibble (bits 68-71) for encoding 490 geo-location and another nibble (bits 64-67) for the use type. 492 IPv6 Routing Plan [IncognitoRoutingPlan] by incognito is advocating 493 allocating bit ranges past an IANA prefix to designate various 494 address attributes, including "subnet types". 496 A.6. Geolocation-based addressing method for IPv6 addresses 498 Qualcomm US patent 7,929,535 [GeoAddressPatent] describes a method of 499 embedding geo-location information, such as latitude, longitude, 500 altitude, in predefined ranges of bits of an IPv6 address past their 501 IANA prefix. 503 A.7. Customer IDs in less significant bits 505 CDNs and hosting providers host web sites belonging to multiple 506 customers using shared servers. Due to the lack of support for SNI 507 TLS extension [RFC6066] by some user agents active on the Internet, 508 CDNs resort to using unique IP addresses to identify specific 509 customer domains and, hence, certificates for TLS negotiation. In 510 case of IPv6 addresses, at least some CDNs use the less significant 511 bits of an IPv6 address to identify customer domains (while the more 512 significant bits carry internal routing information). The 513 configuration of systems matching lower bits of IPv6 addresses to 514 individual customer domains must use ad hoc syntax due to the lack of 515 a standard way to express semantics of matching on bit ranges other 516 than address prefixes. 518 Authors' Addresses 520 Igor Lubashev 521 Akamai Technologies 523 EMail: igorlord@alum.mit.edu 525 Erik Nygren 526 Akamai Technologies 528 EMail: erik+ietf@nygren.org 529 URI: http://erik.nygren.org/