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-ion-transition-01.txt < prev    next >
Text File  |  1997-05-05  |  10KB  |  282 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6. Internetworking Over NBMA Working Group                 James V. Luciani
  7. INTERNET-DRAFT                                            (Bay Networks)
  8. <draft-ietf-ion-transition-01.txt>                 Expires November 1997
  9.  
  10.  
  11.  
  12.  
  13.  
  14.                     Classical IP to NHRP Transition
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.    This document is an Internet-Draft.  Internet-Drafts are working
  20.    documents of the Internet Engineering Task Force (IETF), its areas,
  21.    and its working groups.  Note that other groups may also distribute
  22.    working documents as Internet-Drafts.
  23.  
  24.    Internet-Drafts are draft documents valid for a maximum of six months
  25.    and may be updated, replaced, or obsoleted by other documents at any
  26.    time.  It is inappropriate to use Internet-Drafts as reference
  27.    material or to cite them other than as ``work in progress.''
  28.  
  29.    To learn the current status of any Internet-Draft, please check the
  30.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  31.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  32.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  33.    Rim).
  34.  
  35. Abstract
  36.  
  37.    This document describes methods and procedures for the graceful
  38.    transition from an ATMARP LIS[1] to an NHRP LIS[2] network model over
  39.    ATM.
  40.  
  41. 1. Introduction
  42.  
  43.    ATMARP defines an initial application of classical IP and ARP in an
  44.    ATM network environment configured as a LIS[1].  ATMARP only
  45.    considers application of ATM as a direct replacement for the "wires"
  46.    and local LAN segments connecting IP end-stations and routers
  47.    operating in the "classical" LAN-based paradigm. Issues raised by MAC
  48.    level bridging and LAN emulation are beyond its scope.
  49.  
  50.    The NBMA Next Hop Resolution Protocol (NHRP) allows a source station
  51.    (a host or router), wishing to communicate over a Non-Broadcast,
  52.    Multi-Access (NBMA) subnetwork, to determine the internetworking
  53.  
  54.  
  55.  
  56. Luciani                                                         [Page 1]
  57.  
  58. INTERNET-DRAFT                 NBMA NHRP           Expires November 1997
  59.  
  60.  
  61.    layer addresses and NBMA addresses of suitable "NBMA next hops"
  62.    toward a destination station. If the destination is connected to the
  63.    NBMA subnetwork, then the NBMA next hop is the destination station
  64.    itself.  Otherwise, the NBMA next hop is the egress router from the
  65.    NBMA subnetwork that is "nearest" to the destination station.  For
  66.    the purposes of this document, the NBMA network is of type ATM.
  67.  
  68.    It is reasonable to expect that ATMARP Clients and NHRP Clients will
  69.    initially coexist within a LIS.  Thus it is necessary to define a
  70.    service transition and service coexistence document which describes
  71.    the methods and procedures for the graceful transition from an ATMARP
  72.    network model to an NHRP over ATM network model and the coexistence
  73.    of these models within the same LIS [1][2].  In short, NHSs will be
  74.    required to respond to ATMARP Client queries in a fashion which will
  75.    permit continued use of the ATMARP Client within the LIS during the
  76.    ATMARP to NHRP transition period.  Note that this document places no
  77.    protocol requirements upon ATMARP[1] servers.
  78.  
  79.    For the following, it will be assumed that the reader is familiar
  80.    with the terminology as described in [1][2][3].
  81.  
  82. 2. Service Requirements
  83.  
  84.    If NHRP is to be used in a LIS then only NHSs will be used in the
  85.    LIS; that is, there will not be a mixture of NHSs and ATMARP servers
  86.    within the same LIS.  Since ATMARP servers will not be able to
  87.    understand NHCs and since since, as described below, NHSs will
  88.    respond to ATMARP Clients, this is a reasonable simplifying
  89.    restriction.
  90.  
  91.    This document will only address SVC based environments and will not
  92.    address PVC environments.  This document will refer only to ATM AAL5
  93.    as the NBMA and IP as the protocol layer since this ATMARP only
  94.    addresses these protocols.
  95.  
  96. 2.1 NHRP Server Requirements
  97.  
  98.    If NHRP Servers (NHS) are to be deployed in a LIS which contains both
  99.    ATMARP Clients and NHRP Clients then NHSs MUST respond to
  100.    ATMARP_Requests sent by ATMARP Clients in the same fashion that an
  101.    ATMARP Server would respond as described in [1].  To do this, the NHS
  102.    MUST first recognize the LLC/SNAP ATMARP code point with LLC=0xAA-
  103.    AA-03, OUI=0x00-00-00, and ethertype=0x08-06.  Further, the NHS MUST
  104.    recognize the packet formats described in Section 8.7 of [1].
  105.    However, since this document does not extend to PVC environments,
  106.    NHSs MUST only receive/respond to values of ar$op of 1,2,10
  107.    (Decimal).  If an NHS receives an ATMARP message with ar$op values
  108.    other than those previously noted then the NHS MUST discard the
  109.  
  110.  
  111.  
  112. Luciani                                                         [Page 2]
  113.  
  114. INTERNET-DRAFT                 NBMA NHRP           Expires November 1997
  115.  
  116.  
  117.    packet and MUST NOT take any further action.
  118.  
  119.    When an NHS receives a valid (as defined in the previous paragraph)
  120.    ATMARP_Request packet, the NHS MUST follow the rules described in
  121.    Section 8.4 of [1] with the following additional processing:
  122.  
  123.      1) When an ATMARP_Request causes a new table entry in the NHS for an ATMARP Client,
  124.         that table entry MUST be marked as being of type "ATMARP" so that it can be
  125.         differentiated from an NHRP sourced entry.
  126.  
  127.      2) An ATMARP_Request MUST NOT cause an ATMARP_Reply to be sent if that ATMARP_Request
  128.         contains an off-LIS protocol address.  This should never happen because the IP stack
  129.         on the requesting machine should automatically send the packet to the default
  130.         router.  If this does occur then the ATMARP_Request MUST cause an ATMARP_NAK to
  131.         be sent to the originator.
  132.  
  133.    When an NHS receives an ATMARP_Request which causes an update to one
  134.    of its cache entries then that entry is placed on a 20 minute timer
  135.    as described in [1] since ATMARP has no concept of Holding Time
  136.    fields.
  137.  
  138.    An NHS receiving an NHRP Resolution Request MUST NOT send a positive
  139.    NHRP Resolution Reply for a station which registered via ATMARP if
  140.    the station sending the NHRP Resolution Request is outside the LIS of
  141.    the station which registered itself via ATMARP.  This is because the
  142.    station which registered via ATMARP is almost certainly not prepared
  143.    to accept a cut-through.   When this occurs, the replying NHS must
  144.    send NHRP Resolution Reply which contains a CIE code of "12 - No
  145.    Internetworking Layer Address to NBMA Address Binding Exists" as
  146.    described in [2].  This type of reply does not preclude the station
  147.    sending the NHRP Resolution Request from sending its data packets
  148.    along the routed path but it does preclude that station from setting
  149.    up a cut-through VC.
  150.  
  151. 2.2 Multi-server environments
  152.  
  153.    Since NHRP works in a multi-server environment on a per LIS basis, it
  154.    is useful to make a few comments about the cache synchronization
  155.    necessary in a hybrid ATMARP/NHRP LIS.  ATMARP and NHRP have
  156.    different cache overwrite rules.  An NHC is permitted to register its
  157.    addresses with multiple NHSs while ATMARP Clients are not.  The cache
  158.    over-write rules are described in [1][2].
  159.  
  160.    A simple rule of thumb for the synchronization of ATMARP initiated
  161.    entries in an NHS is as follows:
  162.  
  163.      if it were the case that the LIS contained only a single server
  164.      and, as a result of an ATMARP_Request, a cache update would occur
  165.  
  166.  
  167.  
  168. Luciani                                                         [Page 3]
  169.  
  170. INTERNET-DRAFT                 NBMA NHRP           Expires November 1997
  171.  
  172.  
  173.      in that single server then in a multi-server environment the
  174.      resultant cache update MUST be propagated to all NHSs in the LIS.
  175.  
  176.    Further information on cache over-write strategies for ATMARP and
  177.    NHRP servers can be found in [3].
  178.  
  179. 3. Security Considerations
  180.  
  181.    Not all of the security issues relating to IP over ATM are clearly
  182.    understood at this time, due to the fluid state of ATM
  183.    specifications, newness of the technology, and other factors.
  184.  
  185.    It is believed that ATM and IP facilities for authenticated call
  186.    management, authenticated end-to-end communications, and data
  187.    encryption will be needed in globally connected ATM networks.  Such
  188.    future security facilities and their use by IP networks are beyond
  189.    the scope of this memo.
  190.  
  191.    There are known security issues relating to host impersonation via
  192.    the address resolution protocols used in the Internet [4].  No
  193.    special security mechanisms have been added to ATMARP.  While NHRP
  194.    supplies some mechanisms for authentication, ATMARP does not.  Since
  195.    any security mechanism is only as good as its weakest link, it should
  196.    be assumed that when NHRP and ATMARP exist with a given LIS, the
  197.    security of a combination is only as good as that supplied by ATMARP.
  198.  
  199. References
  200.  
  201.    [1] Classical IP and ARP over ATM, Mark Laubach, RFC 1577.
  202.  
  203.    [2] NBMA Next Hop Resolution Protocol (NHRP), Luciani, Katz, Piscitello,
  204.        Cole, draft-ietf-rolc-nhrp-10.txt.
  205.  
  206.    [3] Server Cache Synchronization Protocol (SCSP) - NBMA,
  207.        J. Luciani, G. Armitage, J. Halpern, Work In Progress.
  208.  
  209.    [4] Security Problems in the TCP/IP Protocol Suite, Bellovin,
  210.        ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48,
  211.        1989.
  212.  
  213.  
  214.  
  215.  
  216. Acknowledgments
  217.  
  218.    TBD.
  219.  
  220.  
  221.  
  222.  
  223.  
  224. Luciani                                                         [Page 4]
  225.  
  226. INTERNET-DRAFT                 NBMA NHRP           Expires November 1997
  227.  
  228.  
  229. Author's Addresses
  230.  
  231.  
  232.    James V. Luciani
  233.    Bay Networks
  234.    3 Federal Street
  235.    Mail Stop: BL3-04
  236.    Billerica, MA 01821
  237.    Phone:  +1 508 916 4734
  238.    Email:  luciani@baynetworks.com
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280. Luciani                                                         [Page 5]
  281.  
  282.