home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1955.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  9.9 KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          R. Hinden
  8. Request for Comments: 1955                        Ipsilon Networks, Inc.
  9. Category: Informational                                        June 1996
  10.  
  11.  
  12.     New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG
  13.  
  14. Status of This Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document was submitted to the IETF IPng area in response to RFC
  23.    1550.  Publication of this document does not imply acceptance by the
  24.    IPng area of any ideas expressed within.  Comments should be
  25.    submitted to the big-internet@munnari.oz.au mailing list.
  26.  
  27.    This memo describes a proposal made to to the Routing and Addressing
  28.    group [ROAD] January 1992 by Robert Hinden.  It was originally sent
  29.    as an email message.  It proposes a medium term solution to the
  30.    Internet's routing and addressing problems.
  31.  
  32. INTRODUCTION
  33.  
  34.    I would like to propose a new scheme which I believe is a good medium
  35.    term solution to the routing and address problems of the internet.
  36.    It has the following positive attributes:
  37.  
  38.       - No Changes to Hosts
  39.       - No Changes to Most Routers
  40.       - No New Routing Protocols
  41.       - No New Internet Protocols
  42.       - No Translation of Addresses in Packets
  43.       - Reduces the Routing Table Size in All Routers
  44.       - Uses the Current Internet Address Structure
  45.  
  46.    It is not a solution good for all time, because it does impose some
  47.    size limits and does not support new internet services such as
  48.    guaranteed bandwidth, delay, etc.  It does require border routers to
  49.    do additional processing, but does not require any packet
  50.    translation.  I believe that this scheme will give us enough time to
  51.    put into place a long term solution (i.e. pick one or more of CLNP,
  52.    *NAT, IDPR, IDRP, Nimrod, Unified, NewIP, etc.)
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Hinden                       Informational                      [Page 1]
  59.  
  60. RFC 1955                       IP Encaps                       June 1996
  61.  
  62.  
  63.    This scheme is based on the ideas presented by Deborah Estrin (route
  64.    on ADs), Martha Steenstrup (encapsulation), and probably steals from
  65.    ideas put forward by Noel Chiappa, Van Jacobson , Ross Callon, Dave
  66.    Oran, and everyone else in the ROAD group.
  67.  
  68. CONTEXT
  69.  
  70.    I think that we (the ROAD group) agree that in the short term we need
  71.    to make better use of the IP address space.  I think we also (mostly)
  72.    agree that in the long term we need a solution that can deal with a
  73.    very large number of end points and routes, as well as support new
  74.    services such as guarantees of service, source selected routes, etc.
  75.    We do not agree on any of the details of this but do agree that we
  76.    can not figure out a long term solution before March.  We do agree
  77.    that we should start working on a long term solution(s).
  78.  
  79.    What this leaves is the need for a good medium term solution which
  80.    can keep the Internet going until we can design and deploy a long
  81.    term solution.  The medium term solution wants to be the most "cost
  82.    effective".  It should buy us the most time to develop a long term
  83.    solution and do it with as little change to the existing Internet as
  84.    possible.
  85.  
  86.    I propose this scheme as a new medium term solution.
  87.  
  88. NEW SCHEME
  89.  
  90.    The basic idea is that inter-domain routing be done by routing on
  91.    autonomous domains (AD).  The key is how this is done.  The mechanism
  92.    to do this is for the border routers to encapsulate the original IP
  93.    datagrams with another IP header.  The source and destination
  94.    addresses in the new header (I will call it the AD-Header from here
  95.    on) represent the source and destination ADs.
  96.  
  97.    When the first (entrance) border router receives a datagram from a
  98.    host or router without an AD-Header it looks at the source and
  99.    destination address and does a DNS lookup to get the addresses for
  100.    the AD-Header.  It then adds an AD-Header and forwards the
  101.    encapsulated datagram to its proper destination AD.
  102.  
  103.    The border routers would compute AD routes by running a routing
  104.    protocol between themselves.  BGP or even IS-IS or OSPF for that
  105.    matter, would work fine.  As you will see later, they might even be
  106.    better.
  107.  
  108.    The addresses I propose to use for the AD addresses are plain old IP
  109.    addresses.  A small number of Class A and Class B addresses would be
  110.    reserved for this purpose.  The network number of the address would
  111.  
  112.  
  113.  
  114. Hinden                       Informational                      [Page 2]
  115.  
  116. RFC 1955                       IP Encaps                       June 1996
  117.  
  118.  
  119.    indicate that it was an AD identifier.  The local part of the address
  120.    would indicate the actual AD.  This would allow for many ADs to be
  121.    supported.  For example, 10 Class-A and 10 Class-B addresses could
  122.    accommodate (10*2^24 + 10*2^16) 168,427,500 ADs.  We clearly don't
  123.    need that many for a long time.
  124.  
  125.    The reason why I would chose to get more than one network number to
  126.    use to represent the AD address is I would use them to organize the
  127.    ADs.  Let's call them commonwealths.  Each commonwealth would only
  128.    have to know the detail of it's own ADs.
  129.  
  130.    Next I would have the border routers inject these AD addresses into
  131.    the Intra-AD routing of transit ADs.  They would tell the routers
  132.    inside of the transit AD that they (the border routers) were the
  133.    route to each appropriate AD network.  Commonwealths that have
  134.    multiple interconnects (probably the common case) could by the use of
  135.    careful assignment of the AD addresses use subnetting to support
  136.    reasonable routing between the commonwealths.  This is where OSPF or
  137.    IS-IS might be better than BGP.  Also, IS-IS, with its ability to
  138.    route on actual end points might be the best.
  139.  
  140.    The motivation behind injecting the AD addresses into the Intra-AD
  141.    routing of the transit ADs, is that the routers in these ADs can
  142.    forward the AD-Headers without knowing that they are special.  Only
  143.    the entrance and exit border routers are required to do anything
  144.    different.
  145.  
  146.    Finally when a AD-Header is received at the last (exit) border router
  147.    it strips off the AD-Header and sends the datagram to the final
  148.    destination.
  149.  
  150.    This scheme is based around the idea that IP addresses are globally
  151.    unique.  I think that we will not actually run out of IP addresses
  152.    for a long time and that we can live with the current addressing
  153.    until we can deploy a long term solution.
  154.  
  155.    This scheme could be extended to not require globally unique IP
  156.    address.  Effectively the combination of AD-Address and IP-Address is
  157.    the globally unique address.  To use this scheme without globally
  158.    unique IP-Addresses and without changing in the hosts would require a
  159.    NAT mechanism in the border routers.  I think it would be preferable
  160.    to change the hosts to have them do the DNS query and add the AD-
  161.    header.  This could be the basis for the long term solution.
  162.  
  163.    Another interesting aspect of this scheme is that if we were to relax
  164.    the current architecture where one IP-Address is always in only one
  165.    AD, to allow an IP-Address to be in more than one AD, it would
  166.    provide a solution to the issue of allowing a IP entity to get
  167.  
  168.  
  169.  
  170. Hinden                       Informational                      [Page 3]
  171.  
  172. RFC 1955                       IP Encaps                       June 1996
  173.  
  174.  
  175.    service from more than one service provider.
  176.  
  177. SUMMARY OF CHANGES REQUIRED
  178.  
  179.    The DNS needs to be extended to add an AD-Address entry for each
  180.    name.  These will be used by the entry and exit border routers to get
  181.    the AD-Addresses to use when building the AD-Headers.
  182.  
  183.    Border routers need to be extended to do the DNS lookup, perform AD-
  184.    Header encapsulation, run an inter-AD routing algorithm using AD-
  185.    Addresses, and be able to AD-Header de-encapsulation.
  186.  
  187. CONCLUSION
  188.  
  189.    I believe that this scheme has may advantages.  These are:
  190.  
  191.       - Only border routers and the DNS need change.  No changes are
  192.         required in hosts or non-border routers.
  193.  
  194.       - No performance impact on datagram forwarding except at entry
  195.         and exit border routers.
  196.  
  197.       - Only a small impact on bandwidth utilization on transit
  198.         networks due the addition of a 20 byte IP header to each
  199.         datagram.
  200.  
  201.       - Removes the Inter-AD routing from Intra-AD routing and as a
  202.         result solves the routing load (table size and computation)
  203.         problem for the foreseeable future.
  204.  
  205.       - The routing load on the border routers is manageable because
  206.         border routers only need to know the detail of the routing
  207.         commonwealth they are a member of.  Other commonwealths appear
  208.         as single addresses.
  209.  
  210.       - No requirement for new routing protocols to be designed or
  211.         deployed.
  212.  
  213.       - No translation of packets from one address scheme to another.
  214.  
  215.       - Uses the current IP addressing structure.
  216.  
  217.       - It scales well even if there is on the order of one AD per IP
  218.         network, because the AD-Addresses can be assigned logically.
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Hinden                       Informational                      [Page 4]
  227.  
  228. RFC 1955                       IP Encaps                       June 1996
  229.  
  230.  
  231.    It does have some disadvantages.  These are (at least):
  232.  
  233.       - It is not a long term solution in its initial form.
  234.  
  235.       - It assumes that the current IP-Addresses can remain globally
  236.         unique for a long time.
  237.  
  238. REFERENCES
  239.  
  240.    [ROAD] Gross, P., and P. Almquist, "IESG Deliberations on Routing
  241.           and Addressing", RFC 1380, ANS, Stanford University,
  242.           November 1992.
  243.  
  244. SECURITY CONSIDERATIONS
  245.  
  246.    Security issues are not discussed in this memo.
  247.  
  248. AUTHOR'S ADDRESS
  249.  
  250.    Robert M. Hinden
  251.    Ipsilon Networks, Inc.
  252.    2191 East Bayshore Road
  253.    Suite 100
  254.    Palo Alto, CA 94303
  255.    USA
  256.  
  257.    EMail: hinden@ipsilon.com
  258.    Phone: +1 (415) 846-4604
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Hinden                       Informational                      [Page 5]
  283.  
  284.