idnits 2.17.1 draft-bellovin-piara-framework-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 252 has weird spacing: '...g could be im...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1996) is 10169 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) -- Looks like a reference, but probably isn't: 'RFC1775' on line 63 == Unused Reference: '1' is defined on line 508, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yakov Rekhter 3 Internet Draft Cisco Systems 4 Paul Resnick 5 AT&T 6 Steve Bellovin 7 AT&T 9 Expiration Date: December 1996 June 1996 11 Financial Incentives for Route Aggregation and Efficient Address 12 Utilization in the Internet: A Framework 14 draft-bellovin-piara-framework-00.txt 16 1. Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working doc- 19 uments of the Internet Engineering Task Force (IETF), its areas, and 20 its working groups. Note that other groups may also distribute work- 21 ing documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference mate- 26 rial or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 2. Abstract 36 The ability to sustain continuous growth of the Internet is affected 37 both by the ability of the Internet routing system to scale, and by 38 the availability of IP addresses that are unique within the Internet. 39 We argue that scalable routing and efficient address space utiliza- 40 tion should not be treated as two separate problems, but as two 41 inter-related facets of a single problem - how to scale the Internet. 43 Unfortunately, scalable routing and efficient address space utiliza- 44 tion do not come for free: they sometimes require renumbering of 45 existing hosts to new addresses or otherwise undersirable address 46 allocations. We propose to use financial incentives rather than just 47 the existing methods of persuasion and coercion to motivate IP 48 address assignment that is efficient both with respect to its suit- 49 ability for aggregation (via hierarchical routing), and with respect 50 to the address space utilization. We argue that where tradeoffs must 51 be made between conflicting goals, use of financial incentives will 52 permit local decisions that take into account local differences, thus 53 leading to better choices than could be made by any centralized 54 administrative body. 56 3. Motivations 58 What is the goal ? 60 This document assumes a goal of enabling Internet growth through the 61 smallest resource expenditures possible. For the purpose of this doc- 62 ument, the size of the Internet is measured as the number of hosts 63 that have either full access or client access [RFC1775]. In pursuing 64 the goal of least cost growth, we need to respect the distributed 65 nature of decision-making on the Internet. We cannot expect partici- 66 pants to endure private losses that generate public gains, at least 67 not for an indefinite period of time. 69 We do not claim that the forms of charging discussed here are neces- 70 sary, at least at this time. Rather, we assert that, at the least, 71 monetary mechanisms are a possible alternative solution to the Inter- 72 net's growing pains. As such, they should be explored, much as we 73 explore new technical ideas. Accordingly, our motive in writing this 74 memo is to stimulate discussion of the ideas and issues involved, and 75 -- where necessary -- to begin consideration of any new protocols 76 that might be needed. 78 4. Growth While Minimizing Resource Utilization 80 Suppose a new host joins the Internet. The host needs an unambiguous 81 address and full connectivity. That is, from every existing host 82 there must be at least one path by which packets can travel to the 83 new host. At each step along each of those paths, a router must be 84 able forward packets to the correct next hop. 86 There are two limits, then, on growth. First, there must be an unam- 87 biguous address available for each new host. Second, many routers 88 must keep track of an extra "route", an extra entry in the table of 89 where to forward packets. 91 One could argue that new technology can expand these limits. For 92 example, by moving to IPv6, we can get longer addresses, and hence 93 make available more unambiguous addresses. At least in principle, one 94 could argue that to keep track of extra routes we just need to build 95 routers with more memory. Additional technology, however, is costly 96 and is not always available just when you need it. The technology 97 growth curve may also be unable to keep up with the growth of the 98 Internet. Sometimes it will be either cost effective or just neces- 99 sary to make more efficient use of existing resources instead. 101 Hierarchical route aggregation is one way to make more efficient use 102 of existing resources. While the notion of a route and route aggrega- 103 tion may be applied to various types of route information, this docu- 104 ment focuses on one particular type: addressing information. In par- 105 ticular, if all packets destined for addresses with the same prefix 106 get forwarded to the same next hop, a router can include just one 107 entry in its router table for that prefix, rather than a separate 108 entry for each individual address. This method can be applied recur- 109 sively to create larger and larger address blocks that share shorter 110 and shorter prefixes. Hierarchical route aggregation is widely used 111 on the Internet today and was the main technology behind CIDR [ref.]. 113 Hierarchical aggregation only works, however, if all traffic destined 114 to all the addresses covered by a particular address prefix should be 115 routed to the same next hop. Thus, the assignment of addresses to 116 hosts must follow the connection topology of the network in order for 117 hierarchical aggregation to be successful. 119 Even when address assignments match connection topology sufficiently 120 at one point in time, it's hard to keep them aligned over time. Dif- 121 ficulties arise both from networks that grow and shrink, and from 122 changes in network topology that occur when customers switch 123 providers or peering arrangements change. 125 Consider the growth problem. An organization initially has n hosts to 126 connect, but at a later time may need to connect an as-yet unknown 127 number of additional hosts. There are only three ways to handle this, 128 none of which is completely satisfactory: 130 1) Assign the block of n but leave spare addresses with the same 131 prefix unused in anticipation of future needs. When the addresses 132 are eventually used, they can be routed as a single aggregate. For 133 example, the current RIPE NCC policy is to give out a /19 to a new 134 ISP, but to reserve the companion /19 that shares the same prefix, 135 so that it can also be given to that ISP in the future, thus cre- 136 ating an 18-bit prefix that can all be routed to the same destina- 137 tion. This wastes addresses, however, since the ISP may never need 138 the reserved addreses, and doesn't completely solve the problem, 139 since the ISP may need more addresses than those that have been 140 reserved. 142 2) When additional addreses are needed, renumber the existing n 143 hosts into a larger block that accommodates the additional hosts. 144 The cost of renumbering the existing hosts, however, may be quite 145 high. 147 3) Allocate the additional addresses separately, and advertise an 148 extra route. Because renumbering costs can be high, and addresses 149 may not be reserved, this is a common practice. This imposes a 150 cost on the organizations that must carry the additional route. 152 The best choice will depend on time-varying and local circumstances. 153 If addresses are plentiful, the inefficient address space utilization 154 of the first method may be acceptable. If renumbering costs are low, 155 the second may be appropriate. If routers are not overloaded, the 156 last method may be fine. 158 5. Distributed Decision Making 160 The Internet consists of many independent decision-makers. The self- 161 interest of these decision-makers does not always align with the 162 interests of the Internet as a whole. Even when interests are not 163 aligned, we need to motivate behavior that benefits the Internet as a 164 whole. 166 For subscribers, we need to motivate use of as few addresses as pos- 167 sible, and use of addresses that are suitable for hierarchical aggre- 168 gation. Currently, such address assignment has no immediate and/or 169 direct benefits, but has immediate and obvious drawbacks to a sub- 170 scriber -- the need to renumber whenever they add more hosts. Con- 171 versely, continuing to use non-aggregatable addresses imposes a 172 direct cost on the rest of the Internet: the need for increased 173 router memory. 175 For providers, we need to motivate advertisement of aggregate routes 176 for their subscribers whenever that is possible. In particular, 177 providers should always aggregate their stub subscribers. Currently, 178 providers gain no direct benefits from advertising aggregate routes. 179 In fact, by doing this the provider benefits other providers, who may 180 be the provider's competitors. 182 5.1. The Spirt of Cooperation 184 The "spirit of cooperation" is often invoked when self-interest does 185 not align with the larger interest. It calls on everyone to cooperate 186 with each other and do whatever is necessary for the "goodness of the 187 Internet". We shouldn't underestimate the power of this incentive. 188 The fact that the Internet is still operational is largely due to the 189 "spirit of cooperation". But it is dangerous to rely solely on this 190 spirit, especially as the Internet grows larger and anonymous commer- 191 cial ties replace the personal ties that bound network operators 192 together in the old days. 194 5.2. Administrative Policies 196 Sometimes rules, or policies, can align individual behavior with the 197 common good despite a misalignment of interests. Policies are diffi- 198 cult to enforce, however, because there is no central authority on 199 the Internet. Moreover, as the Internet continues to grow, it becomes 200 ever more difficult even to agree on policies. For example, today 201 there are three major address registries; in general, they co- 202 ordinate their address policies. If several more registries were to 203 come into being, such co-ordination would become more difficult. 204 Such a development is likely, since more than half the population of 205 the planet lives in areas with very little Internet connectivity, and 206 some of these areas have very different economic and social philoso- 207 phies. 209 A final problem with policies is that it is difficult make them 210 reflect the heterogeneity of the Internet. A policy about advertising 211 aggregate routes that is appropriate for organizations with low 212 renumbering costs may not be appropriate for those with higher costs. 213 Similarly, a blanket policy determining the number of addresses to 214 allocate to a new ISP does not take into account the likely growth of 215 the ISP, while an allocation policy that takes into account business 216 plans requires sophisticated, and sometimes subjective, decision- 217 making rules. 219 5.3. Financial Incentives 221 Alternatively, we can use financial incentives to bring individual 222 self-interest into closer alignment with the global interest, thus 223 motivating behavior that serves the common good. For example, if an 224 organization is forced to pay the cost that advertising an additional 225 route imposes on others, it will choose to do so only when its own 226 benefits outweigh the global costs. Similarly, if organizations paid 227 for addresses, they would reserve unused addreses for future use only 228 when the benefits outweighed the cost. As an added feature, the money 229 collected can compensate those entities that actually bear the costs. 231 Decisions based on financial incentives will naturally take into 232 account local factors. If there are charges both for addresses and 233 for advertisement of routes, organizations will trade off these costs 234 against their own costs of renumbering. Since the cost of renumbering 235 will vary between organizations, different organizations will make 236 different tradeoffs. 238 The rest of the document outlines a framework for using financial 239 incentives in conjuction with route advertisements, and address allo- 240 cations. 242 6. Charging for route advertisements 244 The primary goal of introducing charging for route advertisment is to 245 limit the number of routes within the Internet routing system, while 246 still maintaining full IP connectivity. To put it differently, the 247 goal is to propagate each route to as few domains as possible, while 248 maintaining connectivity among as many domains as possible. 250 6.1. Route "push" vs route "pull" 252 To understand how charging could be imposed, we need to examine 253 routing information dissemination. Specifically, we need to differen- 254 tiate between the distribution of routing information that is neces- 255 sary to provide connectivity, and routing information that results in 256 improved connectivity (better paths). 258 6.1.1. Route "push" 260 Route "push" occurs when a provider has a route to reach some desti- 261 nation and offers to others to handle transit traffic, so that they 262 can use the route. This is the natural way to expand the region of 263 hosts with connectivity to a destination. Note, however, that connec- 264 tivity provided by pushing may not yield the most desirable path 265 between the destination and every other host. 267 In the context of hierarchical routing a route has to be "pushed" 268 until it gets aggregated with other routes. In the worst case the 269 route has to be "pushed" first to "default-free" zone of the Inter- 270 net, and then through the whole "default-free" zone. 272 The scope of how far a route has to be "pushed" is influenced by the 273 assignment of the addresses covered by the route. 275 6.1.2. Route "pull" 277 Route "pull" occurs when a provider chooses to use a better route to 278 a destination than the route that was pushed to it, asking providers 279 along the new route to provide transit service. Thus, route "pull" is 280 not necessary to provide connectivity - from the connectivity per- 281 spective route "pull" is optional. The decision on when to "pull" a 282 route is influenced by the tradeoffs between path optimality and the 283 volume of routing information. It is a purely local matter. 285 6.2. Use of bilateral agreements 287 To scale the system we propose that both route "push" and route 288 "pull" be realized solely as a composition of bilateral agreements. 289 Individual agreements will be constrained to the organizations (e.g., 290 providers, subscribers) that are directly connected (thus physical 291 connectivity constrains the number of possible agreements). Composi- 292 tion (including subcontracting) of bilateral agreements enables 293 extension of the scope of "push" or "pull" beyond directly connected 294 providers/subscribers. 296 Suppose X has a route to Z. For X to push the route to another orga- 297 nization Y (directly connected to X), X and Y would sign a "contract" 298 of the form, "I, Y, promise that the following organizations (e.g., 299 providers), ____, will be able to reach destination Z by sending 300 traffic to me (Y), which I will forward to X." Typically, Y would 301 then subcontract with downstream organizations to further push the 302 route. 304 Suppose Y has a route to Z. For an organization X to pull a route 305 from an organization Y (directly connected to X), X and Y would sign 306 a "contract" of the form, "I, Y, promise to forward traffic from X to 307 Z via the following sequence of organizations __________." This 308 requires a bilateral agreement with the first organization in the 309 sequence, which then has a subcontracting agreement with the next 310 organization in the sequence, etc. 312 Both the sign and magnitude of payments accompanying a contract are 313 open to negotiation. For example, in a contract for X to push a route 314 to Y, X might pay Y, which might in turn redistribute some of that 315 payment to the subcontractors it relies on to fulfill the original 316 contract. 318 6.3. Interaction with hierarchical routing 320 The use of provider-based address allocation reduces the scope of 321 route "push" for subscribers. A subscriber needs to "push" just to 322 its provider. A provider that aggregates routes from N of its sub- 323 scribers into a single route will presumably be able to negotiate a 324 more favorable push contract with downstream organizations than a 325 provider that pushes N separate routes for its customers, thus creat- 326 ing an incentive for aggregation. 328 6.4. Interaction with route optimality 330 Aggregation could cause suboptimal routing because the optimal next 331 hop may differ for two destinations whose routes have been aggre- 332 gated. Thus one could argue that any mechanism that encourages aggre- 333 gation could also (indirectly) encourage suboptimal routing. Aggre- 334 gation, however, does not always result in suboptimal routing. For 335 example, aggregation of stub subscribers has no impact on route opti- 336 mality. 338 6.5. Interaction with address allocation policies 340 Charging for route advertisement may make portable addresses (address 341 "ownership" in the language of addr-own...[ref.]) less attractive to 342 small and medium size sites. Since portable addresses will not be 343 easily aggregated, the routing costs of portable addresses will be 344 higher. Those who prefer not to pay these higher costs will accept 345 address allocations from their providers ("address lending.") 347 6.6. Interaction with transit traffic 349 When an organization X contracts to accept traffic from another orga- 350 nization Y, the routing information passed from X to Y would control 351 what destinations Y would be able to reach through X. This would 352 impact the amount of traffic X would receive from Y. X's decision 353 about what routing information to pass to Y could also be affected by 354 Y's charges for routes. 356 Thus, the amount of routing information that X would pass to Y would 357 represent a balance between the amount of traffic X is willing to 358 accept from Y, and the charges for routes that Y would impose when 359 accepting routes from X. (Clearly, this concept is also related to 360 settlements payments for traffic. If X can profit by carrying traf- 361 fic from Y, it will be more willing to pay the cost of advertising 362 more routes.) 364 7. Charging for Address Allocation 366 While charging for route advertisement may motivate address assign- 367 ment that is efficient with respect to its suitability for aggrega- 368 tion, it does little (or nothing) to produce efficient address space 369 utilization. To improve address space utilization we propose to 370 charge for addresses, thus motivating transfer of addresses to those 371 who value them most. 373 7.1. "Transferable address ownership" address allocation policy 375 In the current model, when an organization acquires addresses based 376 on the "address ownership" policy, the organization can take the 377 addresses with them when switching providers, but the organization 378 can't transfer the ownership to another organization. The organiza- 379 tion could only either loan these addresses to another organization, 380 or return these addresses back to the Internet Registry that provided 381 the initial allocation. 383 Address lending policy allows transfer of addresses from one organi- 384 zation to another, but the transfer is expected to be on a temporary 385 basis, and is also expected to be coupled with the connectivity 386 between two organizations. 388 Neither of these policies is ideal for introduction of charges for 389 address allocation. Charges, or taxes, could be introduced in the 390 non-transferable address ownership situation, but there would be no 391 market forces operating to discover the appropriate level of charges. 392 It is also unclear to whom the charges would be paid. Charges are a 393 natural part of address lending, but when customers switch providers 394 they have no way to trade off the costs of renumbering against addi- 395 tional routing costs that come with address portability. 397 Instead, a third policy, transferrable address ownership, is needed. 398 The transferable address ownership policy could be viewed as a gener- 399 alization of the address lending policy, where the loan is not 400 bounded by a specific time period or connectivity, and is recursive. 401 The transferable address ownership policy could also be viewed as a 402 relaxation of the current address ownership policy, where an organi- 403 zation may transfer ownership of its addresses to another organiza- 404 tion. 406 For an organization that wants to acquire addresses, the purchase 407 price would create an incentive to use as few addresses as possible. 409 For organizations that already own addresses, the opportunity cost of 410 not selling unneeded addresses would create the same incentive. 412 7.2. Scope of ownership 414 Transferable address ownership is defined with respect to a particu- 415 lar set of organizations that are willing to honor the ownership 416 right. We'll refer to this set as a "club" The address ownership 417 rights mean that address assignment consistent with the right would 418 result in unambiguous routing to this address from any host within 419 the organizations that are willing to honor the rights. One could 420 also observe that the property right results in unique address 421 assignment within the club. 423 We can operationally define the address property right in terms of an 424 ownership database consisting of ownership deeds for or blocks of IP 425 addresses. The club is defined as the set of organizations who agree 426 to respect the database entries, refusing to route data (within the 427 club) destined for a particular address except as authorized to do so 428 by the owner of the address. 430 The model doesn't preclude an organization being in more than one 431 club. However, membership in more than one club can't violate owner- 432 ship right of any member of any of these clubs. Clubs can be inter- 433 connected by any mechanism that doesn't pass unmodified IP addresses. 434 These include NAT boxes and some forms of firewall. 436 7.3. Address ownership without connectivity 438 The transferrable address ownership policy doesn't couple acquisition 439 of the address ownership rights with the actual connectivity. Owning 440 a (transferrable) address without having global routability may have 441 what economists call "option value." That is, there is value in hav- 442 ing the option of global routability sometime in the future. For 443 example, this would permit an organization to change its style of 444 firewall without incurring the cost of renumbering. 446 7.4. Interaction with hierarchical routing 448 The market price of address blocks is likely to be influenced by 449 route charges. In particular, a large block of addresses that share a 450 common prefix is likely to sell for more than an equivalent number of 451 addresses that do not share a common prefix: it will be cheaper to 452 contract for routing of the large block than the collection of 453 smaller blocks. 455 7.5. Address Ownership Registry 457 If addresses are to be owned by individual parties, it is necessary 458 to have some way to ascertain who owns -- and has the right to have 459 routed -- each address. This can be accomplished in a number of 460 ways. 462 The most obvious is to continue the present registry system. The 463 various registries already maintain such lists; making addresses 464 transferrable will presumably increase the rate of change of owner- 465 ship, but to a first approximation imposes no serious problems. Any- 466 one wishing to confirm the validity of a routing change request can 467 simply consult the registry, and notify the owner-of-record of the 468 change. 470 Companies that desire confidentiality in address ownership could use 471 the service of a third party. This third party would be the listed 472 owner of record, and would have to initiate any change requests; how- 473 ever, rather than acting on its own, it would act based on instruc- 474 tions from the real owner. Negotiations, including any provisions 475 for audit trails, contract provisions, escrow or bonding money, etc., 476 would be determined by bilateral negotiations between the owner and 477 the third party, and would be outside the scope of this document. 479 We could accomplish the same thing technically, if we wished. The 480 registry could list a public cryptographic key with each address; all 481 change requests would be signed by the corresponding private key. 482 Transaction types would include rekeying, to allow for ownership 483 changes; additionally, address blocks could be subdivided, in which 484 case a new public key would be specified for each new block. If 485 desired, change requests could even be accompanied by an anonymous 486 digital cash payment, to reimburse the registry for its administra- 487 tive overhead. 489 8. Summary 491 The current routing and addressing situation in the Internet is 492 unstable. 494 Avoiding facing the problem of scaling the Internet woudn't make the 495 problem to go away. 497 The combination of charging for address allocation and for route 498 advertisement could lead to an address assignment that is efficient 499 both with respect to the address space utilization, and the ability 500 to perform hierarchical aggregation of addressing information. 502 9. Security Considerations 504 Security issues are not discussed in this document. 506 10. References 508 [1] R. Myerson and M. Satterthwaite, "Efficient Mechanisms 509 for Bilateral Trade," Journal of Economic Theory, vol. 28, pp. 510 265-281, 1983. 512 11. Acknowledgements 514 To be supplied. 516 12. Author Information 518 Yakov Rekhter 519 cisco Systems, Inc. 520 170 Tasman Dr. 521 San Jose, CA 95134 522 Phone: (914) 528-0090 523 email: yakov@cisco.com 525 Paul Resnick 526 AT&T Research 527 600 Mountain Avenue 528 Murray Hill, NJ 07974 529 Phone: (908) 582-5370 530 email: presnick@research.att.com 532 Steven M. Bellovin 533 AT&T Research 534 600 Mountain Avenue 535 Murray Hill, NJ 07974 536 Phone: (908) 582-5886 537 email: smb@research.att.com