idnits 2.17.1 draft-ietf-ipngwg-ipv6-routing-00.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-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. ** 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 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 are 78 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 8 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 119: '...hat router implementations MUST NOT by...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 9 has weird spacing: '... Drafts are ...' == Line 10 has weird spacing: '...cuments of t...' == Line 11 has weird spacing: '...ups may also ...' == Line 15 has weird spacing: '... Drafts may b...' == Line 16 has weird spacing: '...iate to use ...' == (73 more instances...) -- 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 (28 October 1996) is 10034 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) ** Obsolete normative reference: RFC 1883 (ref. 'DH96') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1519 (ref. 'FLYV93') (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1933 (ref. 'GN96') (Obsoleted by RFC 2893) ** Obsolete normative reference: RFC 1884 (ref. 'HD96') (Obsoleted by RFC 2373) -- Possible downref: Non-RFC (?) normative reference: ref. 'MM96' -- Possible downref: Non-RFC (?) normative reference: ref. 'CFM96' -- Possible downref: Non-RFC (?) normative reference: ref. 'RT96' Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Randall Atkinson 2 Internet Draft cisco Systems 3 draft-ietf-ipngwg-ipv6-routing-00.txt 28 October 1996 5 IPv6 Routing Table Size Issues 7 STATUS OF THIS MEMO 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of 6 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as "work in 18 progress". 20 This particular Internet Draft is intended for submission to the 21 IETF's IPng working group for possible future publication as a 22 standards-track or informational RFC. 24 ABSTRACT 26 This note describes certain issues relating to the size of the IPv6 27 routing table in backbone routers. It also suggests several possible 28 approaches to dealing with those issues. 30 1. INTRODUCTION 31 IP version 6 (IPv6) is being developed within the IETF as a long- 32 term replacement for the current IP version 4 (IPv4). [DH96] As part 33 of IPv6 development, a set of IPv4-compatible IPv6 addresses have 34 been defined. [GN96] These addresses are 128 bits long and consist of 35 a fixed 96 bit prefix and then contain an embedded 32-bit IPv4 36 address in the low-order portion of the address. [HD96] 38 In the current IPv4 backbone, the size of the IPv4 routing table is 39 a significant operational issue. Although the deployment of CIDR 40 [FLYV93] has significantly reduced the rate of increase of the total 41 set of IPv4 routes, the total number of such routes continues to 42 increase. For the purpose of this discussion, a backbone router is 43 defined as a router that contains all IPv4 routes except for the 44 "default" route. As of this writing, a backbone router carries 45 perhaps 47,000 IPv4 routes, including about 30,000 routes that are 46 external to the router's own network and perhaps 17,000 routes that 47 are internal to the router's own network and hence cannot be 48 aggregated. A number of activities performed by a router have costs 49 proportional to the total size of the routing table. Both size and 50 growth rate of the total set of IPv4 routes is a significant 51 operational issue for backbone networks. 53 Deployment of IPv6 in a backbone will increase the number of total 54 routes that backbone routers have to carry. To the extent that IPv6 55 addresses can be aggregated more effectively than IPv4 routes have 56 been, the issues posed by deployment of a second network-layer 57 protocol can be mitigated. However, each IPv6 routing prefix is 128 58 bits long as compared with the 32 bits for an IPv4 routing prefix. 59 The overall size of a routing table entry varies significantly in 60 different implementations of IPv6 routing, but it is very clear that 61 carrying an IPv4 prefix once natively and a second time as if it were 62 an IPv6 prefix causes significant increase in routing table size. 63 Even if an IPv6 route entry were the same size as an IPv4 route 64 entry, the router would need twice the memory for the routing table. 65 This is a significant operational issue in default-less routers. 67 2. ALTERNATIVE APPROACHES 69 There are at least three possible approaches to this issue. This 70 section discusses these alternatives and the issues associated with 71 each. 73 2.1 Do Nothing 74 This is the simplest alternative. It involves taking no particular 75 actions to preclude backbone routing tables from increasing in size. 76 This approach might work if backbone operational networks obtain and 77 deploy routers capable of handling the significantly larger number of 78 backbone routes. 80 2.2 Route Filtering 81 One alternative is for network operators concerned about this issue 82 to filter the routes that they accept via their routing protocols so 83 that IPv4-compatible IPv6 prefixes are not accepted into the routing 84 table and are not propogated within that operator's routing domain. 85 This can work but potentially consumes significant amounts of a 86 router's resources, potentially adversely impact the forwarding rate 87 of the routers engaged in such filtering. Some believe that this 88 would also break IPv6 routing. 90 2.3 Avoid carrying IPv4-compatible Routing Prefixes 91 Another alternative is to avoid carrying IPv4-compatible IPv6 92 routing prefixes as if they were native IPv6 routing prefixes. In 93 this alternative, the routing protocol specifications would prohibit 94 IPv4-compatible IPv6 routing prefixes as native IPv6 prefixes. Of 95 course, native IPv4 prefixes that were indicated as being IPv4 96 prefixes could still be carried by an routing protocol supporting 97 integrated routing (e.g. I/ISIS). 99 In this approach, a dual-stack (IPv4 and IPv6) router that received 100 a native unencapsulated IPv6 packet destined for an IPv4-compatible 101 IPv6 address that did not have an IPv6 route for that particular 102 IPv4-compatible IPv6 address would immediately encapsulate that IPv6 103 packet inside IPv4 and forward it in tunneled form to the IPv4 104 destination address. This would involve increased cost (due to the 105 encapsulation) at the outer edge routers and would eliminate IPv4- 106 compatible IPv6 addresses as a potential source of greatly increased 107 routing tables for the backbone routers. 109 Because the existence of an IPv4 route in an IPv4 routing table 110 does not provide any information about whether the next hop is also 111 capable of handling IPv6 packets, encapsulation of the IPv6 packet 112 inside the IPv4 packet prior to forwarding is necessary unless the 113 forwarding node has certain knowledge that the next-hop address for 114 the IPv4 route is also capable of handling IPv6 packets. 116 3. PROPOSED ACTION 118 It is proposed that the specifications for IPv6-capable routing 119 protocols clearly indicate that router implementations MUST NOT by 120 default inject any part of their logical IPv4 routing table into 121 their logical IPv6 routing table, that such specifications note the 122 operational issue that is described in this note, and that such 123 specifications discourage implementers from permitting such cross- 124 protocol route injection from occurring. Of course, if the operator 125 of the router explicitly chose to inject IPv4-compatible IPv6 routes 126 into the IPv6 routing table and live with the results, this would not 127 be prohibited. The affected routing protocols appear to include 128 OSPFv3 [CFM96], RIPv2 for IPv6 [MM96], I/ISIS, and IDRPv2 [RT96]. 130 Dual-stack routers not having an explicit route for an IPv4- 131 compatible IPv6 address will be required to always encapsulate all 132 IPv6 packets forwarded to an IPv4-compatible IPv6 destination address 133 inside IPv4 and then use the IPv4 routing table to lookup paths to 134 IPv4-compatible destination addresses. Encapsulation is generally 135 required before forwarding for the reason outlined in the previous 136 section. 138 4. SECURITY CONSIDERATIONS 140 It is possible to take out an operational network through 141 inappropriate injection of incorrect routes. It is also possible to 142 take out an operational network by injecting more routes than that 143 network's routing systems are able to cope with. These can occur 144 through operator error as well as through the malicious actions of 145 third parties. Intentional injection of too many routes into a 146 network's routing system such that the victim network ceases proper 147 operation constitutes a denial of service attack. 149 REFERENCES 150 [DH96] Steve Deering & Robert Hinden, "IP version 6 Specification", 151 RFC-1883, January 1996. 153 [FLYV93] V. Fuller, T. Li, J. Yu, & K. Varadhan, "Classless Inter-Domain 154 Routing (CIDR): an Address Assignment and Aggregation Strategy", 155 RFC-1519, September 1993. 157 [GN96] Bob Gilligan & Erik Nordmark, "Transition Mechanisms for IPv6 Hosts 158 and Routers", RFC-1933, April 1996. 160 [HD96] Robert Hinden & Steve Deering, "IP version 6 Addressing Architecture", 161 RFC-1884, January 1996. 163 [MM96] Gary Malkin & R. Minnear, "RIPng for IPv6", Internet Draft, 164 August 1996. 166 [CFM96] Rob Coltun, Dennis Ferguson, & John Moy, "OSPF for IPv6", Internet 167 Draft, June 1996. 169 [RT96] Yakov Rekhter & Paul Traina, "Inter-Domain Routing Protocol 170 Version 2", Internet Draft, June 1996. 172 AUTHOR'S ADDRESS: 174 Randall Atkinson 175 cisco Systems 176 170 West Tasman Drive 177 San Jose, CA 95134-1706 USA 179 Email: rja@cisco.com 180 Telephone: +1 (408) 526-6566 182 --