idnits 2.17.1 draft-ietf-cidrd-classa-01.txt: 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-25) 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There is 1 instance of too long lines in the document, the longest one being 15 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 113 has weird spacing: '...default route...' == Line 114 has weird spacing: '...ctively calcu...' == Line 228 has weird spacing: '...routing adver...' == Line 288 has weird spacing: '...routing proto...' -- 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 (December 1995) is 10359 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) == Unused Reference: 'CIDR' is defined on line 371, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Huston 2 INTERNET-DRAFT Telstra Internet 4 5 December 1995 7 Observations on the use of Components of the Class A 8 Address Space within the Internet 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet- 25 Drafts Shadow Directories on ds.internic.net (US East Coast), 26 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 27 munnari.oz.au (Pacific Rim). 29 Abstract 31 This document is a commentary on the recommendation that IANA 32 commence allocation of the presently unallocated components of the 33 Class A address space to registries, for deployment within the 34 Internet as class-less address blocks. 36 The document examines the implications for service providers and end 37 clients within this environment. The document notes the major 38 conclusion that widespread adoption of class-less routing protocols 39 is required, within a relatively rapid timeframe for this 40 recommendation to be effective. 42 Introduction 44 The Address Lifetime Expectancy (ALE) Working Group of the IETF has 45 recorded the allocation of Internet addresses from the unallocated 46 address pool. ALE has noted that the existing practice of drawing 47 addresses from the Class C space (192/3 address prefix) will result 48 in near to medium term exhaustion of this section of the unallocated 49 address pool. The largest remaining pool is in the Class A space, 50 where some 25% of Internet addresses (the upper half of the Class A 51 space) remain, to date, unallocated. 53 This document is a commentary on the potential recommendation that 54 the Internet Assigned Numbers Authority (IANA), through delegated 55 registries, commence allocation of the presently unallocated 56 components of the Class A address space to registries, for 57 deployment within the Internet through the mechanism of allocation 58 of class-less address prefixes. 60 The deployment of class-less address prefixes from the Class A space 61 within the Internet will require some changes to the routing 62 structure within Internet component network domains. The motivation 63 for, and nature of, such changes as they effect network domains and 64 network service providers are outlined in this document. 66 Current Practice with Address Allocations 68 To date the allocation of class-less network prefixed address blocks 69 has followed a conservative practice of using address allocations 70 which are compatible superblocks of Class C addresses, while the 71 allocation of addresses within the space of Class A and Class B 72 networks has continued to be aligned with the class-based prefix 73 structure. 75 Within this address allocation environment for non-transit network 76 domains there is accordingly the option to continue to use address 77 deployment strategies which involve fixed subnet address structures 78 within contiguous areas, and use Class-full interior routing 79 protocols. In the situation where variable length subnet masks or 80 disconnected subnets are deployed within the network domain's routing 81 structure, interior routing protocols which use subnet-based routing 82 of Class-full networks can still be successfully deployed and the end 83 network has the option of using an explicit or implicit sink subnet 84 default route. Where such non-transit network domains are connected 85 to the Internet infrastructure the boundary exchange between the 86 non-transit network and the network service provider (this term is 87 used as a synonym for a transit network domain, which provides a 88 traffic transit service to other non-transit and peer transit network 89 domains) is either a class-full advertisement of routes, or an 90 aggregated address advertisement where the aggregate is a superblock 91 of the deployed component class-full networks. At the boundary points 92 of the non-transit network it is a requirement that the non-transit 93 network's subnet default route (if used explicitly) not be directed 94 to the network service provider's domain, to avoid a routing loop at 95 the domain boundary point. 97 For network service providers the interior routing protocol can use 98 either aggregated routing or explicit class-full routing within this 99 environment. At the network service provider's boundary peering 100 points the strongly recommended practice is to advertise aggregated 101 routes to transit peers, which in turn may be further aggregated 102 across the Internet, within the parameters of permissible policies. 104 Implications of Address Allocation from the Class A space 106 Network Service Providers Must Use Class-less Routing 108 For network service providers within the deployed Internet the 109 implications from this recommendation to deploy prefixes from the 110 Class A address space add more pressure to the requirement to 111 uniformly deploy class-less routing protocols. While this is already 112 a mandatory requirement for any domain which operates without a 113 default route (ie. the provider carries full Internet routing and 114 effectively calculates default), other providers currently can use 115 an imported default route and operate within a class-full routing 116 configuration. This mode of operation is sub-optimal, in so far as 117 the task of aggregating routes falls on peer network service 118 providers performing proxy aggregation of contiguous class-full 119 address blocks. 121 In deploying components of the Class A the use of proxy aggregation 122 is no longer sufficient. Where a domain sees a default route and a 123 subnet of a Class A route the routing structure, in a class-full 124 configuration, may not necessarily follow the default route to reach 125 other parts of the Class A network not covered by the advertised 126 Class A subnet route. 128 Accordingly for Network Service Providers operating within the 129 Internet domain the deployment of components of the Class A space 130 entails a requirement to deploy class-less routing protocols, even in 131 the presence of a default route. It is noted that this absolute 132 requirement is not the case at present. 134 Consideration of Non-Transit Network Configurations 136 For disconnected network environments, where the network domain is 137 operated with no links to any peer networking domain, such networks 138 can continue to use class-full interior routing protocols with subnet 139 support. Allocation of addresses using prefix blocks from the Class A 140 space within such environments is possible without adding any 141 additional routing or address deployment restrictions on the network 142 domain. 144 For non-transit network domains which are connected to one or more 145 peer network domains the situation does involve consideration of 146 additional factors. The observation which is made in the context of 147 this consideration is that there are at present relatively few non- 148 transit networks operating a fully class-less interior routing 149 protocol, as there has been no absolute requirement for this 150 functionality when using single class-full network addresses, or when 151 using block prefixed address allocations which are clusters of class- 152 full network addresses. 154 For non-transit network domains which support external peer 155 connections to a network service provider, deployment of a component 156 of the Class A space would be supportable using a fully class-less 157 interior routing protocol. 159 In this case there is an additional constraint placed on the external 160 connection such that the non-transit domain either agrees that the 161 network service will undertake proxy aggregation of the advertised 162 class-less address components, or the network domain is configured to 163 advertise to the provider an aggregate route. In both cases the 164 aggregate route must be either the allocated address block, or a 165 fully contained sub-block. Advertising aggregatable address blocks 166 without proxy aggregation permission, or advertising multiple sub- 167 blocks of the registry allocated address block is considered overly 168 deleterious to the provider's internetworking environment due to 169 considerations of consequent growth in routing table size. 171 If the externally connected non-transit network domain uses class- 172 full interior routing protocols then deployment of Class A address 173 space prefixes implies that the domain must configure the Class A 174 subnet default route along the same path as the default route to the 175 network service provider (which is noted to be the exact opposite of 176 the necessary routing configuration for those address prefixes which 177 are either aligned to class-full address boundaries or are super 178 blocks of such class-full address blocks). The network service 179 provider may also receive leaked explicit subnet reachability 180 information in such a routing configuration, potentially placing the 181 responsibility for advertising the correct aggregate address block 182 with the network service provider as a case of proxied aggregation. 184 Within this configuration model, even when explicit subnet default 185 routing is deployed, there is the risk of unintentional traffic 186 leakage and routing loops. If the network service provider is 187 undertaking proxy aggregation using the registry allocated address 188 block then traffic originating within the non-transit domain which is 189 (mis)directed to non-deployed components of the address block will 190 loop at the interface between the network domain and the provider. If 191 the network service provider is configured to explicitly route only 192 those address components which are also explicitly routed within the 193 non-transit domain, such (mis)directed traffic will be passed through 194 the internetworking environment along the default route until a 195 default-less routing point is encountered, where it can then be 196 discarded. The outcome of this consideration is that the non-transit 197 network domain should explicitly configure sink subnet routes for all 198 non-deployed components of the allocated address block, and 199 conservative operational practice would be to configure the proxy 200 aggregation undertaken by the network service provider to aggregate 201 according to the registry allocated address block. 203 There is an additional constraint placed on the non-transit network 204 domain using class-full interior routing protocols, such that the 205 domain has no other exterior peer connections to other network 206 domains which deploy class-full routing interior routing protocols. 208 There is the further constraint placed on the of use of interior 209 class-full routing protocols within a non-transit network domain. In 210 the case where the non-transit network domain has multiple exterior 211 connections to Network Service Providers (ie the network domain is 212 multiply homed within a number of network providers) there is the 213 possibility that each provider may wish to announce components of the 214 same Class A parent. Accordingly the network domain must use a class- 215 less interior routing protocol in the case where the network domain 216 is multiply homed within network service providers. 218 There are also additional constraints placed on the non-transit 219 network domain where the network has exterior connections to other 220 peer networks. Even in the case where the network domain uses a 221 class-less interior routing protocol, there is the additional 222 consideration that this requirement for use of a class-less routing 223 domain is transitive to other connected network domains. An second 224 network domain, externally connected to the class-less domain routing 225 part of the Class A space, will interpret the boundary reachability 226 advertisement as a complete Class A network advertisement, if using 227 class-full routing. Even if both network domains are connected to the 228 same network provider the provider's default routing advertisement 229 default to the class-full domain will be overridden by the assumed 230 class A advertisement through the domain-to-domain connection, 231 leading to unintended traffic diversion. The diversion occurs in this 232 case as the traffic directed to parts of the Class A network which 233 are not deployed within the first domain will transit the first 234 domain before entering the network service provider's domain. 236 It is also possible to have configurations with unintended routing 237 holes. An example of such a configuration is two stub clients of 238 different network service providers, both using class-less interior 239 routing (X and Y), both directly connected to a third network domain 240 (Z), which uses class-full interior routing, which is configured as a 241 transit between X and Y. X's advertisement of a component of a Class 242 A to Z will be assumed by Z to be a complete Class A network, and as 243 such will be advertised to Y, overriding Y's default route received 244 from the network service provider. Y will pass all Class A addressed 245 traffic to Z, who will in turn pass it to X. As X is configured as a 246 non-transit stub network X must discard all non-locally addressed 247 traffic. 249 Thus reasonable operational practice would be to ensure that if a 250 network domain deploys a component of the Class A address space, the 251 network domain is configured to use class-less interior routing 252 protocols, and the network has a single exterior connection to a 253 class-less network provider domain, with the boundary configured as a 254 class-less routing exchange. Multiply homed network domains do infer 255 a common requirement of class-less routing exchanges and interior 256 class-less routing protocols across all peer connected network 257 domains. 259 It is possible to propose that multi homed network domains should 260 probably not get subnets of a class A for these reasons, although 261 with an increasing diversity of network service providers instances 262 of multi-homed network domains may become more prevalent, and the 263 requirement to transition to an interior class-less routing structure 264 as a consequence of moving to a multi-homed configuration may not be 265 explicitly apparent to all network domains. 267 Potential Guidelines for Allocation of an Address Prefix from the Class A Address Space 269 To summarise the possible guidelines for allocation from the Class A 270 space, such addresses should only be assigned to network domains 271 which: 273 - have no exterior connection (in which case the domain can use 274 either class-full or class-less interior routing protocols without 275 further implication), 277 or 279 - are a component of a private internet domain which uses class-full 280 routing exchanges and no other part of the same Class A is 281 assigned into the domain (this is probably an unlikely scenario 282 given a probable direction to use the Class A space as the major 283 resource for the unallocated pool of addresses for allocation), 285 or 287 - have a single default exterior connection to a class-less routing 288 domain, use class-full routing protocols and explicitly direct a 289 subnet default route to the exterior connection, 291 or 293 - use class-less interior routing protocols and connect only to 294 other network domains which also use class-less interior routing 295 protocols. 297 It is a reasonable objective to nominate a transition objective to 298 the final configuration (uniform use of class-less routing domains 299 within the Internet) which would enable deployment of components 300 of the Class A space uniformly across the Internet. 302 Related Potential Activities 304 Given the pressures on the remaining Class C address space in the 305 unallocated address pool, it is noted that there would be widespread 306 deployment of components of the remaining Class A space in class-less 307 allocation guidelines. There is a consequent requirement for 308 widespread deployment of class-less interior routing protocols in 309 order to ensure continued correct operation of the routed Internet. 310 This is a more significant transition than that deployed to date with 311 the network service providers' deployment of Class-less Inter-Domain 312 Routing (CIDR) protocols, in that there is a necessary transition to 313 deploy Class-less Interior Routing Protocols (CIRP) within a large 314 number of network domains which are currently configured with class- 315 full routing. 317 However this would appear to be a necessary task if we wish to 318 continue to utilise a pool of globally unique Internet addresses to 319 allocate to new systems and networks, but one requiring significant 320 effort considering the space of the routing transition required to 321 make this work. 323 There are a number of directed activities which can assist in this 324 transition: 326 - The network registries commence initial class-less allocation from 327 the unallocated Class A space to those entities who either: 329 o operate a CIRP environment, and either have no external 330 connectivity, or are singly homed to a network service provider 331 using a CIDR environment, with no other exterior connections, 333 or 334 o operate a class-full routing protocol, and either have no 335 external connectivity, or are singly homed to a network service 336 provider using a CIDR environment, with no other exterior 337 connections, and are willing to point the subnet default route 338 towards the network service provider. 340 - In deploying the Class A space there is a requirement within the 341 vendors' product sets to allow explicit configuration of whether 342 the router operates in a class-less or class-full mode, with 343 correct behaviour of the default route in each case. Class-full 344 mode of operation must also allow explicit configuration of 345 subnet default behaviour as to whether to follow the default 346 route, or to operate a subnet default sink. 348 - There is a similar, but longer term, activity within the host 349 configuration environment to support a mode of address 350 configuration which uses a local network prefix and host address, 351 possibly in addition to the current configuration mode of class- 352 full network, subnet and host address 354 - Internet Service Providers also must support full class-less 355 configurations in both interior routing configurations and 356 interdomain peering routing exchanges, and provide support to 357 client network domains operating a class-less boundary routing 358 exchange configuration and be able to undertake proxy aggregation 359 as permitted. 361 Security Considerations 363 Correct configuration of the routing environment of the Internet is 364 essential to the secure operation of the Internet. 366 The potential use of the Class A space raises no additional 367 considerations in this area. 369 References 371 [CIDR] 372 Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter- 373 Domain Routing (CIDR): an Address Assignment and Aggregation 374 Strategy", RFC 1519, BARRnet, cisco, MERIT, OARnet, September 375 1993. 377 Author's Address 379 Geoff Huston 380 Telstra Internet 381 Locked Bag 5744 382 Canberra ACT 2601 383 Australia 385 phone: +61 6 208 1908 386 email: gih@telstra.net