home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1879.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  10.3 KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                 B. Manning, Editor
  8. Request for Comments: 1879                                           ISI
  9. Category: Informational                                     January 1996
  10.  
  11.  
  12.                        Class A Subnet Experiment
  13.                       Results and Recommendations
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Discussion/Purpose
  22.  
  23.    This memo documents some experiences with the RFC 1797 [1] subnet A
  24.    experiment (performed by the Net39 Test Group (see credits)) and
  25.    provides a number of recommendations on future direction for both the
  26.    Internet Registries and the Operations community.
  27.  
  28.    Not all proposed experiments in RFC 1797 were done. Only the "case
  29.    one" type delegations were made.  Additional experimentation was done
  30.    within the DNS service, by supporting a root nameserver and the
  31.    primary for the domain from within the subnetted address space.  In
  32.    addition, testing was done on classless delegation [2].
  33.  
  34.    Internet Services offered over the RFC 1797 experiment were:
  35.  
  36.          Finger
  37.          HTTP
  38.          Telnet
  39.          FTP server/client
  40.          Gopher
  41.          kerberos
  42.          lpr (and its ilk)
  43.          X
  44.          DNS
  45.  
  46.    F.Root-Servers.Net, a root name server had an interface defined as
  47.    part of the RFC 1797 experiment.  Attached is a report fragment on
  48.    it's performance: "My root server has processed 400,000,000 queries
  49.    in the last 38 days, and well over half of them were to the temporary
  50.    39.13.229.241 address (note that I retained the old 192.5.5.241
  51.    address since I knew a lot of folks would not update their root.cache
  52.    files and I didn't want to create a black hole.)" - Paul Vixie
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Manning                      Informational                      [Page 1]
  59.  
  60. RFC 1879               Class A Subnet Experiment            January 1996
  61.  
  62.  
  63.    Initial predictions [3] seemed to indicate that the safest path for
  64.    an ISP that participates in such a routing system is to have -all- of
  65.    the ISP clients be either:
  66.  
  67.                 a) singly connected to one upstream ISP
  68.         OR
  69.                 b) running a classless interior routing protocol
  70.  
  71.    It is also noted that a network with default route may not notice it
  72.    has potential routing problems until it starts using subnets of
  73.    traditional A's internally.
  74.  
  75. Problems & Solutions
  76.  
  77. Operations
  78.  
  79.    There were initial problems in at least one RIPE181 [4]
  80.    implementation.  It is clear that operators need to register in the
  81.    Internet Routing Registry (IRR) all active aggregates and delegations
  82.    for any given prefix.  Additionally, there need to be methods for
  83.    determining who is authoritative for announcing any given prefix.
  84.  
  85.    It is expected that problems identified within the confines of this
  86.    experiment are applicable to some RFC 1597 prefixes or any "natural"
  87.    class "A" space.
  88.  
  89.    Use of traceroute (LSRR) was critical for network troubleshooting
  90.    during this experiment. In current cisco IOS, coding the following
  91.    statement will disable LSRR and therefore inhibit cross-provider
  92.    troubleshooting:
  93.  
  94.                 no ip source-route
  95.  
  96.    We recommend that this statement -NOT- be placed in active ISP cisco
  97.    configurations.
  98.  
  99.    In general, there are serious weaknesses in the Inter-Provider
  100.    cooperation model and resolution of these problems is outside the
  101.    scope of this document. Perhaps the IEPG or any/all of the national
  102.    or continental operations bodies [5] will take this as an action item
  103.    for the continued health and viability of the Internet.
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Manning                      Informational                      [Page 2]
  115.  
  116. RFC 1879               Class A Subnet Experiment            January 1996
  117.  
  118.  
  119. Routing
  120.  
  121.    A classic cisco configuration that has the following statements
  122.  
  123.                 ip route 39.1.28.0 255.255.255.0
  124.                 router bgp 64000
  125.                 redistribute static
  126.  
  127.    will, by default, promote any classful subnet route to a full
  128.    classful route (supernet routes will be left alone).  This behaviour
  129.    can be changed in at least the following two ways:
  130.  
  131.         1:
  132.                 ip route 39.1.28.0 255.255.255.0
  133.                 router bgp 64000
  134.                 no auto-summary
  135.                 redistribute static
  136.  
  137.         2:
  138.                 ip route 39.1.28.0 255.255.255.0
  139.                 router bgp 64000
  140.                 network 39.1.28.0 mask 255.255.255.0
  141.                 redistribute static route-map static-bgp
  142.                 ....
  143.                 access-list 98 deny 39.1.28.0 0.255.255.255
  144.                 access-list 98 permit any
  145.                 ....
  146.                 route-map static-bgp
  147.                 match ip address 98
  148.  
  149.    Users of cisco gear currently need to code the following two
  150.    statements:
  151.  
  152.                 ip classless
  153.                 ip subnet-zero
  154.  
  155.    The implication of the first directive is that it eliminates the idea
  156.    that if you know how to talk to a subnet of a network, you know how
  157.    to talk to ALL of the network.
  158.  
  159.    The second is needed since it is no longer clear where the all-ones
  160.    or all-zeros networks are [6].
  161.  
  162.    Other infrastructure gear exhibited similar or worse behaviour.
  163.    Equipment that depends on use of a classful routing protocol, such a
  164.    RIPv1 are prone to misconfiguration.  Tested examples are current
  165.    Ascend and Livingston gear, which continue to use RIPv1 as the
  166.    default/only routing protocol.  RIPv1 use will create an aggregate
  167.  
  168.  
  169.  
  170. Manning                      Informational                      [Page 3]
  171.  
  172. RFC 1879               Class A Subnet Experiment            January 1996
  173.  
  174.  
  175.    announcement.
  176.  
  177.    This pernicious use of this classful IGP was shown to impact
  178.    otherwise capable systems.  When attempting to communicate between an
  179.    Ascend and a cisco the promotion problem identified above, was
  180.    manifest. The problem turned out to be that a classful IGP (RIPv1)
  181.    was being used between the Ascends and ciscos. The Ascend was told to
  182.    announce 39.1.28/24, but since RIPv1 can't do this, the Ascend
  183.    instead sent 39/8.  We note that RIPv1, as with all classful IGPs
  184.    should be considered historic.
  185.  
  186.    This validates the predictions discussed in [3].
  187.  
  188. Cisco Specific Examples
  189.  
  190.    There are actually three ways to solve the unintended aggregation
  191.    problem, as described with current cisco IOS.  Which of them applies
  192.    will depend on what software version is in the router. Workarounds
  193.    can be implemented for ancient (e.g., 8.X) version software.
  194.  
  195.         o Preferred solution: turn on "ip classless" in the
  196.           routers and use a default route inside the AS.
  197.           The "ip classless" command prevents the existence of
  198.           a single "subnet" route from blocking access via the
  199.           default route to other subnets of the same old-style network.
  200.           Default only works with single-homed ISPs.
  201.  
  202.         o Workaround for 9.1 or later software where the
  203.           "ip classless" command is not available: install a
  204.           "default network route" like this:
  205.           "ip route 39.0.0.0 255.0.0.0 <next-hop>" along the axis
  206.           the default route would normally take.  It appears
  207.           an ISP can utilize the "recursive route lookups" so
  208.           the "next-hop" may not actually need to be a directly
  209.           connected neighbour -- the internal router can e.g.,
  210.           point to a loopback interface on the border router.
  211.           This can become "really uncomfortably messy" and it may
  212.           be necessary to use a distribute-list to prevent
  213.           the announcement of the shorter mask.
  214.  
  215.         o Workaround for 9.0 or older software: create a
  216.           "default subnet route": "ip route 39.x.y.0 <next-hop>"
  217.           combined with "ip default-network 39.x.y.0", otherwise
  218.           as the 9.1 fix.
  219.  
  220.    Both of the latter solutions rely on manual configuration, and in the
  221.    long run these will be impossible to maintain.  In some topologies
  222.    the use of manual configuration can be a problem (e.g., if there is
  223.  
  224.  
  225.  
  226. Manning                      Informational                      [Page 4]
  227.  
  228. RFC 1879               Class A Subnet Experiment            January 1996
  229.  
  230.  
  231.    more than one possible exit point from the AS to choose from).
  232.  
  233. Recommendations:
  234.  
  235.    The RFC 1797 experiment appears to have been a success. We believe it
  236.    safe to start carving up "Class A" space, if the spaces are delegated
  237.    according to normal IR conventions [7] and recommend the IANA
  238.    consider this for future address delegations.
  239.  
  240. Credits:
  241.  
  242.    Thanks to all the RFC 1797 participants. Particular thanks to Paul
  243.    Vixie, Geert Jan de Groot, and the Staff of the IETF33 Terminal room.
  244.    Other thanks to ACES, MCI, Alternet, IIJ, UUNET-Canada, Nothwestnet,
  245.    BBN-Planet, cisco systems, RIPE, RIPE NCC, ESnet, Xlink, SURFnet,
  246.    STUPI, Connect-AU, INBEnet, SUNET, EUnet, InterPath, VIX.COM,
  247.    MindSpring.  Especial thanks to Suzanne Woolf for cleanup.
  248.  
  249. References:
  250.  
  251.    [1] IANA, "Class A Subnet Experiment", RFC 1797, USC/Information
  252.        Sciences Institute, April 1995.
  253.  
  254.    [2] Eidnes, H., and G. J. de Groot, "Classless in-addr.arpa
  255.        delegation", Work in Progress, SINTEF RUNIT, RIPE NCC, May 1995.
  256.  
  257.    [3] Huston, G., "Observations on the use of Components of the Class A
  258.        Address Space within the Internet", Work in Progress, AARnet, May
  259.        1995.
  260.  
  261.    [4] Bates, T., et.al, "Representation of IP Routing Policies in a
  262.        Routing Registry", RFC 1786, MCI, March 1995.
  263.  
  264.    [5] http://info.ra.net/div7/ra/Ops.html, November 1995.
  265.  
  266.    [6] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC
  267.        1812, cisco systems, June 1995.
  268.  
  269.    [7] Hubbard, K., Kosters, M., Conrad, D., and D. Karrenberg,
  270.        "Internet Registry Guidelines", Work in Progress, InterNIC,
  271.        APNIC, RIPE, November 1995.
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Manning                      Informational                      [Page 5]
  283.  
  284. RFC 1879               Class A Subnet Experiment            January 1996
  285.  
  286.  
  287. Security Considerations
  288.  
  289.    Security issues were not considered in this experiment.
  290.  
  291. Editor's Address:
  292.  
  293.    Bill Manning
  294.    Information Sciences Institute
  295.    University of Southern California
  296.    4676 Admiralty Way
  297.    Marina del Rey, CA 90292-6695
  298.    USA
  299.  
  300.    Phone: +1 310-822-1511 x387
  301.    Fax:   +1 310-823-6714
  302.    EMail: bmanning@isi.edu
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Manning                      Informational                      [Page 6]
  339.  
  340.