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