home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_i
/
draft-ietf-ipngwg-ipv6-routing-00.txt
< prev
next >
Wrap
Text File
|
1996-10-29
|
10KB
|
231 lines
Network Working Group Randall Atkinson
Internet Draft cisco Systems
draft-ietf-ipngwg-ipv6-routing-00.txt 28 October 1996
IPv6 Routing Table Size Issues
STATUS OF THIS MEMO
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its working groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of 6
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as "work in
progress".
This particular Internet Draft is intended for submission to the
IETF's IPng working group for possible future publication as a
standards-track or informational RFC.
ABSTRACT
This note describes certain issues relating to the size of the IPv6
routing table in backbone routers. It also suggests several possible
approaches to dealing with those issues.
1. INTRODUCTION
IP version 6 (IPv6) is being developed within the IETF as a long-
term replacement for the current IP version 4 (IPv4). [DH96] As part
of IPv6 development, a set of IPv4-compatible IPv6 addresses have
been defined. [GN96] These addresses are 128 bits long and consist of
a fixed 96 bit prefix and then contain an embedded 32-bit IPv4
address in the low-order portion of the address. [HD96]
In the current IPv4 backbone, the size of the IPv4 routing table is
a significant operational issue. Although the deployment of CIDR
[FLYV93] has significantly reduced the rate of increase of the total
Atkinson Expires in 6 months [Page 1]
Internet Draft IPv6 Routing Table Issues 28 Oct 1996
set of IPv4 routes, the total number of such routes continues to
increase. For the purpose of this discussion, a backbone router is
defined as a router that contains all IPv4 routes except for the
"default" route. As of this writing, a backbone router carries
perhaps 47,000 IPv4 routes, including about 30,000 routes that are
external to the router's own network and perhaps 17,000 routes that
are internal to the router's own network and hence cannot be
aggregated. A number of activities performed by a router have costs
proportional to the total size of the routing table. Both size and
growth rate of the total set of IPv4 routes is a significant
operational issue for backbone networks.
Deployment of IPv6 in a backbone will increase the number of total
routes that backbone routers have to carry. To the extent that IPv6
addresses can be aggregated more effectively than IPv4 routes have
been, the issues posed by deployment of a second network-layer
protocol can be mitigated. However, each IPv6 routing prefix is 128
bits long as compared with the 32 bits for an IPv4 routing prefix.
The overall size of a routing table entry varies significantly in
different implementations of IPv6 routing, but it is very clear that
carrying an IPv4 prefix once natively and a second time as if it were
an IPv6 prefix causes significant increase in routing table size.
Even if an IPv6 route entry were the same size as an IPv4 route
entry, the router would need twice the memory for the routing table.
This is a significant operational issue in default-less routers.
2. ALTERNATIVE APPROACHES
There are at least three possible approaches to this issue. This
section discusses these alternatives and the issues associated with
each.
2.1 Do Nothing
This is the simplest alternative. It involves taking no particular
actions to preclude backbone routing tables from increasing in size.
This approach might work if backbone operational networks obtain and
deploy routers capable of handling the significantly larger number of
backbone routes.
2.2 Route Filtering
One alternative is for network operators concerned about this issue
to filter the routes that they accept via their routing protocols so
that IPv4-compatible IPv6 prefixes are not accepted into the routing
table and are not propogated within that operator's routing domain.
This can work but potentially consumes significant amounts of a
router's resources, potentially adversely impact the forwarding rate
of the routers engaged in such filtering. Some believe that this
would also break IPv6 routing.
Atkinson Expires in 6 months [Page 2]
Internet Draft IPv6 Routing Table Issues 28 Oct 1996
2.3 Avoid carrying IPv4-compatible Routing Prefixes
Another alternative is to avoid carrying IPv4-compatible IPv6
routing prefixes as if they were native IPv6 routing prefixes. In
this alternative, the routing protocol specifications would prohibit
IPv4-compatible IPv6 routing prefixes as native IPv6 prefixes. Of
course, native IPv4 prefixes that were indicated as being IPv4
prefixes could still be carried by an routing protocol supporting
integrated routing (e.g. I/ISIS).
In this approach, a dual-stack (IPv4 and IPv6) router that received
a native unencapsulated IPv6 packet destined for an IPv4-compatible
IPv6 address that did not have an IPv6 route for that particular
IPv4-compatible IPv6 address would immediately encapsulate that IPv6
packet inside IPv4 and forward it in tunneled form to the IPv4
destination address. This would involve increased cost (due to the
encapsulation) at the outer edge routers and would eliminate IPv4-
compatible IPv6 addresses as a potential source of greatly increased
routing tables for the backbone routers.
Because the existence of an IPv4 route in an IPv4 routing table
does not provide any information about whether the next hop is also
capable of handling IPv6 packets, encapsulation of the IPv6 packet
inside the IPv4 packet prior to forwarding is necessary unless the
forwarding node has certain knowledge that the next-hop address for
the IPv4 route is also capable of handling IPv6 packets.
3. PROPOSED ACTION
It is proposed that the specifications for IPv6-capable routing
protocols clearly indicate that router implementations MUST NOT by
default inject any part of their logical IPv4 routing table into
their logical IPv6 routing table, that such specifications note the
operational issue that is described in this note, and that such
specifications discourage implementers from permitting such cross-
protocol route injection from occurring. Of course, if the operator
of the router explicitly chose to inject IPv4-compatible IPv6 routes
into the IPv6 routing table and live with the results, this would not
be prohibited. The affected routing protocols appear to include
OSPFv3 [CFM96], RIPv2 for IPv6 [MM96], I/ISIS, and IDRPv2 [RT96].
Dual-stack routers not having an explicit route for an IPv4-
compatible IPv6 address will be required to always encapsulate all
IPv6 packets forwarded to an IPv4-compatible IPv6 destination address
inside IPv4 and then use the IPv4 routing table to lookup paths to
IPv4-compatible destination addresses. Encapsulation is generally
required before forwarding for the reason outlined in the previous
section.
Atkinson Expires in 6 months [Page 3]
Internet Draft IPv6 Routing Table Issues 28 Oct 1996
4. SECURITY CONSIDERATIONS
It is possible to take out an operational network through
inappropriate injection of incorrect routes. It is also possible to
take out an operational network by injecting more routes than that
network's routing systems are able to cope with. These can occur
through operator error as well as through the malicious actions of
third parties. Intentional injection of too many routes into a
network's routing system such that the victim network ceases proper
operation constitutes a denial of service attack.
REFERENCES
[DH96] Steve Deering & Robert Hinden, "IP version 6 Specification",
RFC-1883, January 1996.
[FLYV93] V. Fuller, T. Li, J. Yu, & K. Varadhan, "Classless Inter-Domain
Routing (CIDR): an Address Assignment and Aggregation Strategy",
RFC-1519, September 1993.
[GN96] Bob Gilligan & Erik Nordmark, "Transition Mechanisms for IPv6 Hosts
and Routers", RFC-1933, April 1996.
[HD96] Robert Hinden & Steve Deering, "IP version 6 Addressing Architecture",
RFC-1884, January 1996.
[MM96] Gary Malkin & R. Minnear, "RIPng for IPv6", Internet Draft,
August 1996.
[CFM96] Rob Coltun, Dennis Ferguson, & John Moy, "OSPF for IPv6", Internet
Draft, June 1996.
[RT96] Yakov Rekhter & Paul Traina, "Inter-Domain Routing Protocol
Version 2", Internet Draft, June 1996.
AUTHOR'S ADDRESS:
Randall Atkinson
cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706 USA
Email: rja@cisco.com
Telephone: +1 (408) 526-6566
Atkinson Expires in 6 months [Page 4]
--