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