idnits 2.17.1 draft-eastlake-6man-hide-options-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 19, 2021) is 920 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) == Outdated reference: A later version (-10) exists of draft-ietf-v6ops-hbh-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Eastlake 2 Intended status: Proposed Standard Futurewei Technologies 3 Expires: April 18, 2022 October 19, 2021 5 Transient Hiding of Hop-by-Hop Options 6 8 Abstract 9 There are increasing requests for a variety IPv6 hop-by-hop options 10 but such IPv6 options and all IPv4 options, are poorly handled, 11 particularly by high-speed routers in the core Internet where packets 12 having options are commonly discarded. This document proposes a 13 simple method of transiently hiding such options for part of a 14 packet's path to protect the packet from discard. 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 Distribution of this document is unlimited. Comments should be sent 22 to the IPv6 Maintenance Working Group mailing list <6man@ietf.org> or 23 to the authors. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 37 Shadow Directories can be accessed at 38 https://www.ietf.org/shadow.html. 40 Table of Contents 42 1. Introduction............................................3 43 1.1 Conventions Used in This Document......................3 45 2. IP Options and Option Handling Problems.................4 47 2.1 IPv6 Options...........................................5 48 2.2 IPv4 Options...........................................6 50 3. Overview of a Solution..................................8 51 3.1 Transiently Hiding IPv6 Options........................9 52 3.2 Transiently Hiding IPv4 Options........................9 53 3.3 Evolution to Greater Option Support...................10 55 4. IANA Considerations....................................11 56 5. Security Considerations................................11 57 6. Acknowledgements.......................................11 59 Normative References......................................12 60 Informative References....................................12 62 Authors' Address..........................................14 64 1. Introduction 66 As discussed in [Options3] there are increasing requests for a 67 variety IPv6 hop-by-hop options but such IPv6 options and all IPv4 68 options, are poorly handled, particularly by high-speed routers in 69 the core Internet where packets having options are commonly 70 discarded. This document proposes a simple method of transiently 71 hiding such options for part of a packet's path to protect the packet 72 from discard. 74 1.1 Conventions Used in This Document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 78 "OPTIONAL" in this document are to be interpreted as described in BCP 79 14 [RFC2119] [RFC8174] when, and only when, they appear in all 80 capitals, as shown here. 82 Terms: 84 ASIC - Application Specific Integrated Circuit. 86 field - an area of one or more contiguous bits within a larger 87 structure. 89 2. IP Options and Option Handling Problems 91 This Section 2 is informational and intended to provide background 92 information. 94 In the early days of the Internet, much of the traffic was text, 95 transmission speeds were slow and IP routers were commonly small 96 general-purpose computers. Under these conditions, parsing IP headers 97 with various options or combinations of options, handling variable 98 length options, etc., was relatively easy. 100 However, as the Internet increased in size, bandwidth grew including 101 more voluminous media such as video, transmission speeds increased 102 enormously, and latency/responsiveness requirements became much more 103 stringent. This leads to IP routers, especially in the core of the 104 Internet, becoming less flexible and more specialized. To be able to 105 handle data faster and more efficiently, such core IP routers are 106 divided into a forwarding plane and a control plane where the 107 forwarding plan handles the usual data forwarding while the control 108 plan handles routing control messages and other packets that the data 109 plane cannot handle. In some IP routers, the forwarding plane is 110 implemented with Application Specific Integrated Circuits (ASICs) 111 that are inflexible and may need fields they examine in an IP packet 112 header to be at a fixed offset from the beginning of the packet. 113 Meanwhile, the control plane may be implemented through a relatively 114 low power general purpose computer which can only handle a small 115 number of packets per unit time. 117 For these reasons, many IP routers do not implement many or any types 118 of IPv6 Hop-by-Hop options or IPv4 header options except through the 119 control plane which is relatively slow. Sending packets with such 120 options to the control plane can overwhelm the control plane and 121 interfere with routing control messages or other critical functions. 122 Very often, particularly for IP routers handling a large volume of 123 traffic, a strategy is adopted of dropping IP packets with such 124 header options or ignoring IPv4 header options and IPv6 Hop-by-Hop 125 header options. 127 See [Options3] for a further discussion of these option handling 128 problems. 130 Further details concerning IPv6 and IPv4 options are given in the 131 subsections below. 133 2.1 IPv6 Options 135 Figure 1 shows the IPv6 header [RFC8200]. The value of the initial 136 4-bit Version field indicates the IP version number and has the value 137 6. 139 0 1 2 3 140 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 |Version| Traffic Class | Flow Label | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Payload Length | Next Header | Hop Limit | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | | 147 + + 148 | | 149 + Source Address + 150 | | 151 + + 152 | | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 + + 156 | | 157 + Destination Address + 158 | | 159 + + 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 1: IPv6 Header 165 The value of the 8-bit Next Header field specifies the type and 166 format of information immediately following the header. For example, 167 a value of 17 in the Next Header field indicates that the header is 168 immediately followed by a User Datagram Protocol (UDP) message and a 169 value of 6 would indicate the header is followed by a Transmission 170 Control Protocol (TCP) message. In some cases, the data immediately 171 after the IPv6 header can be a header that itself includes a Next 172 Header field for the type of data following it and so on as shown in 173 Figure 2. Such headers, after the initial IPv6 header and before the 174 main payload, are called Extension Headers and can be viewed as 175 extensions to the IPv6 header. At this time, specified extension 176 headers include the six listed below, additional extension headers 177 have been proposed, and likely more extension headers will be 178 proposed and specified in the future. 180 Specified extension headers: 181 Hop-by-Hop Options 182 Fragment 183 Destination Options 184 Routing 185 Authentication 186 Encapsulating Security Payload 188 In the two "options" types of extension header, the "Hop-by-Hop 189 Options" and "Destination Options", the extension header content is 190 further structured into options each of which, except for a one byte 191 "pad1" option, is an 8-bit type followed by an 8-bit option length, 192 followed by the option value. Hop-by-Hop options were initially 193 specified to require that every router pay attention to them. While 194 this has been relaxed in the most recent IPv6 specification, they are 195 still frequently viewed as imposing a burden on every IP router 196 through which they pass. 198 0 1 2 3 199 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Next Header | Hdr Ext Len | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 203 | | 204 . . 205 . Options . 206 . . 207 | | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 2: IPv6 Option Extension Header 212 2.2 IPv4 Options 214 Figure 3 shows the IPv4 header [RFC791]. The value of the initial 215 4-bit Version field indicates the IP version number and has value 4. 217 The IPv4 header has many similarities to the iPv6 header. For 218 example, the IPv4 header 8-bit field called "Protocol" is like the 219 "Next Header" field in the IPv6 header and the IPv4 header 8-bit 220 "Type of Service" field, as amended by RFCs issued after [RFC791], is 221 the same as the IPv6 header "Traffic Class" field. But options that 222 are integrated into the more complex IPv4 header are handled by 223 separate header extensions in IPv6. For example consider 224 fragmentation, where an Internet Protocol packet is split into 225 pieces, because the packet might be too big to traverse part of its 226 path, and these pieces are later recombined. Fragmentation is 227 indicated through an extension header for IPv6 but through fields in 228 the main IPv4 header for IPv4. IPv4 options are considered part of 229 the IPv4 header and the size of the options can be determined from 230 the value of the IHL (Internet Header Length) field which gives the 231 size of the IPv4 header in units of 4-octet words. 233 0 1 2 3 234 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 |Version| IHL |Type of Service| Total Length | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Identification |Flags| Fragment Offset | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Time to Live | Protocol | Header Checksum | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Source Address | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Destination Address | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Options | Padding | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 3: IPv4 Header 251 3. Overview of a Solution 253 Figure 4 shows a very high-level view of a network path between two 254 hosts within local networks through the Internet core. (In reality 255 there will be more levels with a local network, whether a home, 256 office, data center, or whatever, usually connected through one or 257 more levels of lower tier service provider before connecting to a 258 Tier 1 provider that connects to the Internet core also known as the 259 defalt free zone.) 261 - - - - - - - - - - - - - - - - . . - - - - - - - - - - 262 . Network 1 . . Core Internet . 263 . . . . 264 . +------+ +---+ +---+ . . +---+ . 265 . |Host A|---|R10|-...-|R19|------------------|R90| . 266 . +------+ +---+ +---+ . . +---+ . 267 . . . | | . 268 . - - - - - - - - - - - - - - - - . ... 269 . ..... 270 . ....... 271 . ....... 272 - - - - - - - - - - - - - - - - . . ..... 273 . Network 2 . . ... 274 . . . | | . 275 . +------+ +---+ +---+ . . +---+ . 276 . |Host B|---|R20|-...-|R29|------------------|R99| . 277 . +------+ +---+ +---+ . . +---+ . 278 . . . . 279 . - - - - - - - - - - - - - - - - - - - - - - - - - - . 281 Figure 4: High Level View of an Internet Path 283 There are efforts to improve and streamline handling of IPv6 Hop-by- 284 Hop options such as the methods in [Options1] and [Options2]. 285 However, even if such a method were popular and fully deployed in 286 some network areas, there is likely to be substantial delay before it 287 would be deployed in most of the Internet core. While some Internet 288 core routers may ignore options, others discard all packets with 289 options and, as long as there is a significant chance of such 290 discard, options are rendered essentially useless on paths through 291 the core. 293 A solution is to hide options before IP packets arrive at the core. 294 This hiding is done in an easily detectable and reversible fashion so 295 that options can be unhidden after leaving the core. IPv6 Hop-by-Hop 296 options or IPv4 options so hidden might not be effective in the core 297 but the situation is an improvement over the traffic using such 298 options being discarded. 300 This solution requires destination support but that should be 301 knowable in many cases such as traffic between branches of the same 302 company or between a customer and a data center. 304 To obtain more uniform handling of packets in a flow, it may be 305 desireable to treat all packet in the flow as if they had such 306 options in that the packet would be transformed to hide and unhide 307 options even if there were none. This transformation could also be 308 applied to all packets starting with the first hsving a problematic 309 option. 311 3.1 Transiently Hiding IPv6 Options 313 IPv6 Hop-by-Hop options are hidden by replacing the zero Next Header 314 field in the IPv6 Header by the opaque IP protocol number TBD. This 315 is a very simple modification of one 8-bit field in a fixed location 316 that has no effect of the size of the packet. They are unhidden by 317 changing this opaque IP protocol number in the IPv6 header back to 318 zero. The points of hiding and unhiding in the packet's path (or 319 paths if multicast) should be chosen to maximize the routers at the 320 beginning and end of the path (Figure 4) that implement the options 321 seeing the options while minimizing he chance of unwanted packet 322 discard. 324 The use of the opaque IP protocol number can defeat deeper IPv6 325 packet analysis that is intended to identify flows. It is therefore 326 RECOMMENDED that, when this hiding technique is used, the IPv6 header 327 Flow Label field be set [RFC6437] and used to identify flows 328 [RFC6438] [RFC7098]. Using the Flow Label is a good idea anyway since 329 IPv6 extension headers may move some fields on which flow identity 330 might be based, such as port numbers, so deep into a packet that they 331 are hard to use by routers. 333 3.2 Transiently Hiding IPv4 Options 335 A similar technique can be used for hiding IPv4 options but 336 significantly more complex manipulations of the packet are required. 337 As shown in Figure 5, the IPv4 header is made to appear to have no 338 options by setting the IHL (Internet Header Length) field to its 339 minimum value of 5, the Protocol field is changed to the opaque IP 340 protocol number TBD, and the Header Checksum is adjusted to be 341 correct for the optionless header. To be able to restore the IPv4 342 header, the old IHL, Protocol, and Header Checksum fields are saved 343 in a 4-octet word inserted after the Destination Address and before 344 any Options. The placement of the saved fields is such that their 345 alignment within a 4-octet word is the same as in the unmodified IPv4 346 header. The field labeled MBZ MUST be sent as zero and ignored on 347 receipt. 349 0 1 2 3 350 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |Version| IHL=5 |Type of Service| Total Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Identification |Flags| Fragment Offset | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Time to Live |Protocol=Opaque| Adjusted Header Checksum | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Source Address | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Destination Address | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | MBZ |SavdIHL| Saved Protocol| Saved Header Checksum | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Options | Padding | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Figure 5: Modified IPv4 Header 369 These modifications increase the size of the IPv4 packet, increasing 370 the chance that fragmentation or MTU problems could occur. For any 371 node ignorant of the opaque IP protocol number, these modifications 372 will interfere with flow determination based on the traditional 373 5-tuple (source and destination address, source and destination port, 374 and IP protocol) or deep packet inspection. 376 3.3 Evolution to Greater Option Support 378 This solution supports the evolution of the Internet toward more 379 widespread support of options as follows: 381 o As acceptable option support is more widely implemented, probably 382 starting at lower bandwidth routers nearer the edge, the 383 boundaries at which options are hidden and unhidden can migrate 384 closer to the core. 386 o If scattered core routers improve to provide acceptable option 387 support, they can recognize the opaque protocol number and perform 388 options, perhaps in a limited way, on packets where those options 389 are hidden to unimproved routers. 391 4. IANA Considerations 393 IANA is request to assign a number from the "Assigned Internet 394 Protocol Numbers" registry as follows: 396 Decimal Keyword Protocol IPv6 Ex Hdr Reference 397 ------- -------- -------- ----------- -------------- 398 TBD Opaque Opaque [this document] 400 5. Security Considerations 402 The use of the opaque IP Protocol to mask options is intended to 403 defeat normal analysis of the following packet content, specifically 404 options in the IP header. This would make firewalls, deep packet 405 analysis, and the like less effective. On the other hand, firewalls 406 tend to only admit packets with known permissable values in protocol 407 header fields such as the IP protocol field. The rejection by a 408 firewall of a packet with the opaque IP protocol value will protect 409 the nodes behind that firewall from possible damage due to the 410 receipt of a packet modified as specified in this document. If the 411 firewall does know the opaque IP Protocol value, it should be 412 configured to treat packets with that value safely, possibly by 413 reversing the option hiding transformation. 415 Should an IPv6 or IPv4 packet modified to hide options get through to 416 a host, it would likely be discarded due to having an unknown IP 417 Protocol. 419 More TBD 421 6. Acknowledgements 423 The helpful comments of the following are gratefully acknowledged: 425 Peng Shuping 427 Normative References 429 [RFC791] - Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 430 10.17487/RFC0791, September 1981, https://www.rfc- 431 editor.org/info/rfc791 433 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 435 March 1997, . 437 [RFC6437] - Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 438 "IPv6 Flow Label Specification", RFC 6437, DOI 439 10.17487/RFC6437, November 2011, 440 . 442 [RFC6438] - Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 443 for Equal Cost Multipath Routing and Link Aggregation in 444 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 445 . 447 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 448 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 449 2017, 451 [RFC8200] - Deering, S. and R. Hinden, "Internet Protocol, Version 6 452 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, 453 July 2017, https://www.rfc-editor.org/info/rfc8200 455 Informative References 457 [Options1] - Li, Z., Peng, S., and G. Mishra, "Hop-by-Hop Forwarding 458 Options Header", Internet draft-li-6man-hbh-fwd-hdr-01, 459 February 2021, 460 https://datatracker.ietf.org/doc/draft-li-6man-hbh-fwd-hdr/ 462 [Options2] - Hinden, R., and G. Fairhurst, "IPv6 Hop-by-Hop options 463 Processing Procedures", Internet draft-hinden-6man-hbh- 464 processing-01, June 2021, 465 https://datatracker.ietf.org/doc/draft-hinden-6man-hbh- 466 processing/ 468 [Options3] - Peng, S., Li, Z., Xie, C., and Z. Qin, "Operational 469 Issues with Processig of the Hop-by-Hop Options Header", 470 Internet draft-ietf-v6ops-hbh-00, June 2021, 471 https://datatracker.ietf.org/doc/draft-ietf-v6ops-hbh/ 473 [RFC7098] - Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 474 Flow Label for Load Balancing in Server Farms", RFC 7098, DOI 475 10.17487/RFC7098, January 2014, 476 . 478 Authors' Address 480 Donald E. Eastlake 3rd 481 Futurewei Technologies 482 2386 Panoramic Circle 483 Apopka, FL 32703 USA 485 Tel: +1-508-333-2270 486 Email: d3e3e3@gmail.com 488 Copyright and IPR Provisions 490 Copyright (c) 2021 IETF Trust and the persons identified as the 491 document authors. All rights reserved. 493 This document is subject to BCP 78 and the IETF Trust's Legal 494 Provisions Relating to IETF Documents 495 (http://trustee.ietf.org/license-info) in effect on the date of 496 publication of this document. Please review these documents 497 carefully, as they describe your rights and restrictions with respect 498 to this document. Code Components extracted from this document must 499 include Simplified BSD License text as described in Section 4.e of 500 the Trust Legal Provisions and are provided without warranty as 501 described in the Simplified BSD License. The definitive version of 502 an IETF Document is that published by, or under the auspices of, the 503 IETF. Versions of IETF Documents that are published by third parties, 504 including those that are translated into other languages, should not 505 be considered to be definitive versions of IETF Documents. The 506 definitive version of these Legal Provisions is that published by, or 507 under the auspices of, the IETF. Versions of these Legal Provisions 508 that are published by third parties, including those that are 509 translated into other languages, should not be considered to be 510 definitive versions of these Legal Provisions. For the avoidance of 511 doubt, each Contributor to the IETF Standards Process licenses each 512 Contribution that he or she makes as part of the IETF Standards 513 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 514 language to the contrary, or terms, conditions or rights that differ 515 from or are inconsistent with the rights and licenses granted under 516 RFC 5378, shall have any effect and shall be null and void, whether 517 published or posted by such Contributor, or included with or in such 518 Contribution.