home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1707.txt < prev    next >
Text File  |  1996-09-11  |  38KB  |  900 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group:                                       M. McGovern
  8. Request for Comments: 1707                              Sunspot Graphics
  9. Category: Informational                                       R. Ullmann
  10.                                            Lotus Development Corporation
  11.                                                             October 1994
  12.  
  13.  
  14.               CATNIP: Common Architecture for the Internet
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This document was submitted to the IETF IPng area in response to RFC
  25.    1550  Publication of this document does not imply acceptance by the
  26.    IPng area of any ideas expressed within.  Comments should be
  27.    submitted to the big-internet@munnari.oz.au mailing list.
  28.  
  29. Executive Summary
  30.  
  31.    This paper describes a common architecture for the network layer
  32.    protocol. The Common Architecture for Next Generation Internet
  33.    Protocol (CATNIP) provides a compressed form of the existing network
  34.    layer protocols. Each compression is defined so that the resulting
  35.    network protocol data units are identical in format. The fixed part
  36.    of the compressed format is 16 bytes in length, and may often be the
  37.    only part transmitted on the subnetwork.
  38.  
  39.    With some attention paid to details, it is possible for a transport
  40.    layer protocol (such as TCP) to operate properly with one end system
  41.    using one network layer (e.g. IP version 4) and the other using some
  42.    other network protocol, such as CLNP. Using the CATNIP definitions,
  43.    all the existing transport layer protocols used on connectionless
  44.    network services will operate over any existing network layer
  45.    protocol.
  46.  
  47.    The CATNIP uses cache handles to provide both rapid identification of
  48.    the next hop in high performance routing as well as abbreviation of
  49.    the network header by permitting the addresses to be omitted when a
  50.    valid cache handle is available. The fixed part of the network layer
  51.    header carries the cache handles.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. McGovern & Ullmann                                              [Page 1]
  59.  
  60. RFC 1707                         CATNIP                     October 1994
  61.  
  62.  
  63.    The cache handles are either provided by feedback from the downstream
  64.    router in response to offered traffic, or explicitly provided as part
  65.    of the establishment of a circuit or flow through the network. When
  66.    used for flows, the handle is the locally significant flow
  67.    identifier.
  68.  
  69.    When used for circuits, the handle is the layer 3 peer-to-peer
  70.    logical channel identifier, and permits a full implementation of
  71.    network-layer connection-oriented service if the routers along the
  72.    path provide sufficient features. At the same time, the packet format
  73.    of the connectionless service is retained, and hop by hop fully
  74.    addressed datagrams can be used at the same time. Any intermediate
  75.    model between the connection oriented and the connectionless service
  76.    can thus be provided over cooperating routers.
  77.  
  78. CATNIP Objectives
  79.  
  80.    The first objective of the CATNIP is a practical recognition of the
  81.    existing state of internetworking, and an understanding that any
  82.    approach must encompass the entire problem. While it is common in the
  83.    IP Internet to dismiss the ISO with various amusing phrases, it is
  84.    hardly realistic. As the Internet moves into the realm of providing
  85.    real commercial infrastructure, for telephone, cable television, and
  86.    the myriad other mundane uses, compliance with international
  87.    standards is an imperative.
  88.  
  89.    The argument that the IETF need not (or should not) follow existing
  90.    ISO standards will not hold. The ISO is the legal standards
  91.    organization for the planet. Every other industry develops and
  92.    follows ISO standards. There is (no longer) anything special about
  93.    computer software or data networking.
  94.  
  95.    ISO convergence is both necessary and sufficient to gain
  96.    international acceptance and deployment of IPng. Non-convergence will
  97.    effectively preclude deployment.
  98.  
  99.    The CATNIP integrates CLNP, IP, and IPX. The CATNIP design provides
  100.    for any of the transport layer protocols in use, for example TP4,
  101.    CLTP, TCP, UDP, IPX and SPX to run over any of the network layer
  102.    protocol formats: CLNP, IP (version 4), IPX, and the CATNIP.
  103.  
  104. Incremental Infrastructure Deployment
  105.  
  106.    The best use of the CATNIP is to begin to build a common Internet
  107.    infrastructure. The routers and other components of the common system
  108.    are able to use a single consistent addressing method, and common
  109.    terms of reference for other aspects of the system.
  110.  
  111.  
  112.  
  113.  
  114. McGovern & Ullmann                                              [Page 2]
  115.  
  116. RFC 1707                         CATNIP                     October 1994
  117.  
  118.  
  119.    The CATNIP is designed to be incrementally deployable in the strong
  120.    sense: you can plop a CATNIP system down in place of any existing
  121.    network component and continue to operate normally with no
  122.    reconfiguration.  (Note: not "just a little". None at all. The number
  123.    of "little changes" suggested by some proposals, and the utterly
  124.    enormous amount of documentation, training, and administrative effort
  125.    then required, astounds the present authors.) The vendors do all of
  126.    the work.
  127.  
  128.    There are also no external requirements; no "border routers", no
  129.    requirement that administrators apply specific restrictions to their
  130.    network designs, define special tables, or add things to the DNS.
  131.    When the end users and administrators fully understand the combined
  132.    system, they will want to operate differently, but in no case will
  133.    they be forced. Not even in small ways. Networks and end user
  134.    organizations operate under sufficient constraints on deployment of
  135.    systems anyway; they do not need a new network architecture adding to
  136.    the difficulty.
  137.  
  138.    Typically deployment will occur as part of normal upgrade revisions
  139.    of software, and due to the "swamping" of the existing base as the
  140.    network grows. (When the Internet grows by a factor of 5, at least
  141.    80% will then be "new" systems.) The users of the network may then
  142.    take advantage of the new capabilities. Some of the performance
  143.    improvements will be automatic, others may require some
  144.    administrative understanding to get to the best performance level.
  145.  
  146.    The CATNIP definitions provide stateless translation of network
  147.    datagrams to and from CATNIP and, by implication, directly between
  148.    the other network layer protocols. A CATNIP-capable system
  149.    implementing the full set of definitions can interoperate with any
  150.    existing protocol. Various subsets of the full capability may be
  151.    provided by some vendors.
  152.  
  153. No Address Translation
  154.  
  155.    Note that there is no "address translation" in the CATNIP
  156.    specification.  (While it may seem odd to state a negative objective,
  157.    this is worth saying as people seem to assume the opposite.) There
  158.    are no "mapping tables", no magic ways of digging translations out of
  159.    the DNS or X.500, no routers looking up translations or asking other
  160.    systems for them.
  161.  
  162.    Addresses are modified with a simple algorithmic mapping, a mapping
  163.    that is no more than using specific prefixes for IP and IPX
  164.    addresses. Not a large set of prefixes; one prefix. The entire
  165.    existing IP version 4 network is mapped with one prefix and the IPX
  166.    global network with one other prefix. (The IP mapping does provide
  167.  
  168.  
  169.  
  170. McGovern & Ullmann                                              [Page 3]
  171.  
  172. RFC 1707                         CATNIP                     October 1994
  173.  
  174.  
  175.    for future assignment of other IANA/IPv4 domains that are disjoint
  176.    from the existing one.)
  177.  
  178.    This means that there is no immediate effect on addresses embedded in
  179.    higher level protocols.
  180.  
  181.    Higher level protocols not using the full form (those native to IP
  182.    and IPX) will eventually be extended to use the full addressing to
  183.    extend their usability over all of the network layers.
  184.  
  185. No Legacy Systems
  186.  
  187.    The CATNIP leaves no systems behind: with no reconfiguration, any
  188.    system presently capable of IP, CLNP, or IPX retains at least the
  189.    connectivity it has now.  With some administrative changes (such as
  190.    assigning IPX domain addresses to some CLNP hosts for example) on
  191.    other systems, unmodified systems may gain significant connectivity.
  192.    IPX systems with registered network numbers may gain the most.
  193.  
  194. Limited Scope
  195.  
  196.    The CATNIP defines a common network layer packet format and basic
  197.    architecture. It intentionally does not specify ES-IS methods,
  198.    routing, naming systems, autoconfiguration and other subjects not
  199.    part of the core Internet wide architecture. The related problems and
  200.    their (many) solutions are not within the scope of the specification
  201.    of the basic common network layer.
  202.  
  203. Existing Addresses and Network Numbers
  204.  
  205.    The Internet's version 4 numbering system has proven to be very
  206.    flexible, (mostly) expandable, and simple.  In short: it works.
  207.    However, there are two problems. Neither was considered serious when
  208.    the CATNIP was first developed in 1988 and 1989, but both are now of
  209.    major concern:
  210.  
  211.  
  212.    o The division into network, and then subnet, is insufficient.
  213.      Almost all sites need a network assignment large enough to
  214.      subnet. At the top of the hierarchy, there is a need to assign
  215.      administrative domains.
  216.  
  217.    o As bit-packing is done to accomplish the desired network
  218.      structure, the 32-bit limit causes more and more aggravation.
  219.  
  220.    Another major addressing system used in open internetworking is the
  221.    OSI method of specifying Network Service Access Points (NSAPs). The
  222.    NSAP consists of an authority and format identifier, a number
  223.  
  224.  
  225.  
  226. McGovern & Ullmann                                              [Page 4]
  227.  
  228. RFC 1707                         CATNIP                     October 1994
  229.  
  230.  
  231.    assigned to that authority, an address assigned by that authority,
  232.    and a selector identifying the next layer (transport layer) protocol.
  233.    This is actually a general multi-level hierarchy, often obscured by
  234.    the details of specific profiles. (For example, CLNP doesn't specify
  235.    20 octet NSAPs, it allows any length. But various GOSIPs profile the
  236.    NSAP as 20 octets, and IS-IS makes specific assumptions about the
  237.    last 1-8 octets. And so on.)
  238.  
  239.    The NSAP does not directly correspond to an IP address, as the
  240.    selector in IP is separate from the address. The concept that does
  241.    correspond is the NSAP less the selector, called the Network Entity
  242.    Title or NET. (An unfortunate acronym, but one we will use to avoid
  243.    repeating the full term.) The usual definition of NET is an NSAP with
  244.    the selector set to 0; the NET used here omits the 0 selector.
  245.  
  246.    There is also a network numbering system used by IPX, a product of
  247.    Novell, Inc. (referred to from here on as Novell) and other vendors
  248.    making compatible software. While IPX is not yet well connected into
  249.    a global network, it has a larger installed base than either of the
  250.    other network layers.
  251.  
  252. Network Layer Address
  253.  
  254.    The network layer address looks like:
  255.  
  256.       +----------+----------+---------------+---------------+
  257.       |  length  |   AFI    |  IDI ...      | DSP ...       |
  258.       +----------+----------+---------------+---------------+
  259.  
  260.    The fields are named in the usual OSI terminology although that leads
  261.    to an oversupply of acronyms. Here are more detailed descriptions of
  262.    each field:
  263.  
  264.    length: the number of bytes (octets) in the remainder of the
  265.            address.
  266.  
  267.    AFI: the Authority and Format Identifier. A single byte
  268.         value, from a set of well-known values registered by
  269.         ISO, that determines the semantics of the IDI field
  270.  
  271.    IDI: the Initial Domain Identifier, a number assigned by the
  272.         authority named by the AFI, formatted according to the
  273.         semantics implied by the AFI, that determines the
  274.         authority for the remainder of the address.
  275.  
  276.    DSP: Domain Specific Part, an address assigned by the
  277.         authority identified by the value of the IDI.
  278.  
  279.  
  280.  
  281.  
  282. McGovern & Ullmann                                              [Page 5]
  283.  
  284. RFC 1707                         CATNIP                     October 1994
  285.  
  286.  
  287.    Note that there are several levels of authority. ISO, for example,
  288.    identifies (with the AFI) a set of numbering authorities (like X.121,
  289.    the numbering plan for the PSPDN, or E.164, the numbering plan for
  290.    the telephone system). Each authority numbers a set of organizations
  291.    or individuals or other entities. (For example, E.164 assigns
  292.    16172477959 to me as a telephone subscriber.)
  293.  
  294.    The entity then is the authority for the remainder of the address. I
  295.    can do what I please with the addresses starting with (AFI=E.164)
  296.    (IDI=16172477959). Note that this is a delegation of authority, and
  297.    not an embedding of a data-link address (the telephone number) in a
  298.    network layer address. The actual routing of the network layer
  299.    address has nothing to do with the authority numbering.
  300.  
  301.    The domain-specific part is variable length, and can be allocated in
  302.    whatever way the authority identified by the AFI+IDI desires.
  303.  
  304. Network Layer Datagram
  305.  
  306.    The common architecture format for network layer datagrams is
  307.    described below. The design is a balance between use on high
  308.    performance networks and routers, and a desire to minimize the number
  309.    of bits in the fixed header. Using the current state of processor
  310.    technology as a reference, the fixed header is all loaded into CPU
  311.    registers on the first memory cycle, and it all fits within the
  312.    operation bandwidth. The header leaves the remaining data aligned on
  313.    the header size (128 bits); with 64 bit addresses present and no
  314.    options it leaves the transport header 256 bit aligned.
  315.  
  316.    On very slow and low performance networks, the fixed header is still
  317.    fairly small, and could be further compressed by methods similar to
  318.    those used with IP version 4 on links that consider every bit
  319.    precious. In between, it fits nicely into ATM cells and radio
  320.    packets, leaving sufficient space for the transport header and
  321.    application data.
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. McGovern & Ullmann                                              [Page 6]
  339.  
  340. RFC 1707                         CATNIP                     October 1994
  341.  
  342.  
  343.       +---------------+---------------+-+-+-+-+-+-+-+-+---------------+
  344.       |   NLPID (70)  |  Header Size  |D|S|R|M|E| MBZ | Time to Live  |
  345.       +---------------+---------------+-+-+-+-+-+-+-+-+---------------+
  346.       |                 Forward Cache Identifier                      |
  347.       +---------------------------------------------------------------+
  348.       |                      Datagram Length                          |
  349.       +---------------------------------------------------------------+
  350.       |     Transport Protocol        |          Checksum             |
  351.       +---------------------------------------------------------------+
  352.       |               Destination Address ...                         |
  353.       +---------------------------------------------------------------+
  354.       |               Source Address ...                              |
  355.       +---------------------------------------------------------------+
  356.       |               Options ...                                     |
  357.       +---------------------------------------------------------------+
  358.  
  359.  
  360.   NLPID: The first byte (the network layer protocol identifier in OSI)
  361.          is an 8 bit constant 70 (hex). This corresponds to Internet
  362.          Version 7.
  363.  
  364.   Header Length: The header length is a 8-bit count of the number of
  365.          32-bit words in the header. This allows the header to
  366.          be up to 1020 bytes in length.
  367.  
  368.   Flags: This byte is a small set of flags determining the datagram
  369.          header format and the processing semantics. The last three bits
  370.          are reserved, and must be set to zero. (Note that the
  371.          corresponding bits in CLNP version 1 are 001, since this byte
  372.          is the version field. This may be useful.)
  373.  
  374.   Destination Address Omitted: When the destination address omitted
  375.          (DAO) flag is zero, the destination address is present as shown
  376.          in the datagram format diagram. When a datagram is sent with
  377.          an FCI that identifies the destination and the DAO flag is
  378.          set, the address does not appear in the datagram.
  379.  
  380.   Source Address Omitted: The source address omitted (SAO) flag is zero
  381.          when the source address is present in the datagram. When
  382.          datagram is sent with an FCI that identifies the source and the
  383.          SAO flag is set, the source address is omitted from the
  384.          datagram.
  385.  
  386.   Report Fragmentation Done: When this bit (RFD) is set, an intermediate
  387.          router that fragments the datagram (because it is larger than
  388.          the next subnetwork MTU) should report the event with an ICMP
  389.          Datagram Too Big message. (Unlike IP version 4, which uses DF
  390.          for MTU discovery, the RFD flag allows the fragmented datagram
  391.  
  392.  
  393.  
  394. McGovern & Ullmann                                              [Page 7]
  395.  
  396. RFC 1707                         CATNIP                     October 1994
  397.  
  398.  
  399.          to be delivered.)
  400.  
  401.   Mandatory Router Option: The mandatory router option (MRO) flag
  402.          indicates that routers forwarding the datagram must look at the
  403.          network header options.  If not set, an intermediate router
  404.          should not look at the header options.  (But it may anyway;
  405.          this is a necessary consequence of transparent network layer
  406.          translation, which may occur anywhere.)
  407.  
  408.          The destination host, or an intermediate router doing
  409.          translation, must look at the header options regardless of
  410.          the setting of the MRO flag.
  411.  
  412.          A router doing fragmentation will normally only use the F
  413.          flag in options to determine whether options should be copied
  414.          within the fragmentation code path. (It might also recognize
  415.          and elide null options.) If the MRO flag is not set, the router
  416.          may not act on an option even though it copies it properly
  417.          during fragmentation.
  418.  
  419.          If there are no options present, MRO should always be zero, so
  420.          that routers can follow the no-option profile path in their
  421.          implementation.  (Remember that the presence of options cannot
  422.          be divided from the header length, since the addresses are
  423.          variable length.)
  424.  
  425.   Error Report Suppression: The ERS flag is set to suppress the sending
  426.          of error reports by any system (whether host or router)
  427.          receiving or forwarding the datagram. The system may log the
  428.          error, increment network management counters, and take any
  429.          similar action, but ICMP error messages or CNLP error reports
  430.          must not be sent.
  431.  
  432.          The ERS flag is normally set on ICMP messages and other network
  433.          layer error reports. It does not suppress the normal response
  434.          to ICMP queries or similar network layer queries (CNLP echo
  435.          request).
  436.  
  437.          If both the RFD and ERS flags are set, the fragmentation report
  438.          is sent.  (This definition allows a larger range of
  439.          possibilities than simply over-riding the RFD flag would; a
  440.          sender not desiring this behavior can see to it that RFD is
  441.          clear.)
  442.  
  443.   Time To Live: The time to live is a 8-bit count, nominally in seconds.
  444.          Each hop is required to decrement TTL by at least one. A hop
  445.          that holds a datagram for an unusual amount of time (more than
  446.          2 seconds, a typical example being a wait for a subnetwork
  447.  
  448.  
  449.  
  450. McGovern & Ullmann                                              [Page 8]
  451.  
  452. RFC 1707                         CATNIP                     October 1994
  453.  
  454.  
  455.          connection establishment) should subtract the entire waiting
  456.          time in seconds (rounded upward) from the TTL.
  457.  
  458.   Forward Cache Identifier: Each datagram carries a 32 bit field, called
  459.          "forward cache identifier", that is updated (if the information
  460.          is available) at each hop. This field's value is derived from
  461.          ICMP messages sent back by the next hop router, a routing
  462.          protocol (e.g., RAP), or some other method. The FCI is used to
  463.          expedite routing decisions by preserving knowledge where
  464.          possible between consecutive routers. It can also be used to
  465.          make datagrams stay within reserved flows, circuits, and mobile
  466.          host tunnels. If an FCI is not available, this field must be
  467.          zero, the SAO and DAO flags must be clear, and both destination
  468.          and source addresses must appear in the datagram.
  469.  
  470.   Datagram Length: The 32-bit length of the entire datagram in octets.
  471.          A datagram can therefore be up to 4294967295 bytes in overall
  472.          length.  Particular networks normally impose lower limits.
  473.  
  474.   Transport Protocol: The transport layer protocol. For example, TCP is
  475.          6.
  476.  
  477.   Checksum: The checksum is a 16-bit checksum of the entire header,
  478.          using the familiar algorithm used in IP version 4.
  479.  
  480.   Destination: The destination address, a count byte followed by the
  481.          destination NSAP with the zero selector omitted. This field is
  482.          present only if the DAO flag is zero. If the count field is not
  483.          3 modulo 4 (the destination is not an integral multiple of
  484.          32-bit words) zero bytes are added to pad to the next multiple
  485.          of 32 bits. These pad bytes are not required to be ignored:
  486.          routers may rely on them being zero.
  487.  
  488.   Source: The source address, in the same format as the destination.
  489.          Present only if the SAO flag is zero. The source is padded in
  490.          the same way as destination to arrive at a 32-bit boundary.
  491.  
  492.   Options: Options may follow. They are variable length, and always
  493.          32-bit aligned. If the MRO flag in the header is not set,
  494.          routers will usually not look at or take action on any option,
  495.          regardless of the setting of the class field.
  496.  
  497. Multicasting
  498.  
  499.    The multicast-enable option permits multicast forwarding of the
  500.    CATNIP datagram on subnetworks that directly support media layer
  501.    multicasting. This is a vanishing species, even in 10 Mbps Ethernet,
  502.    given the increasing prevalence of switching hubs. It also (perhaps
  503.  
  504.  
  505.  
  506. McGovern & Ullmann                                              [Page 9]
  507.  
  508. RFC 1707                         CATNIP                     October 1994
  509.  
  510.  
  511.    more usefully) permits a router to forward the datagram on multiple
  512.    paths when a multicast routing algorithm has established such paths.
  513.    There is no option data.
  514.  
  515.    Note that there is no special address space for multicasting in the
  516.    CATNIP. Multicast destination addresses can be allocated anywhere by
  517.    any administration or authority. This supports a number of differing
  518.    models of addressing. It does require that the transport layer
  519.    protocol know that the destination is multicast; this is desirable in
  520.    any case. (For example, the transport will probably want to set the
  521.    ERS flag.)
  522.  
  523.    On an IEEE 802.x (ISO 8802.x) type media, the last 23 bits of the
  524.    address (not including the 0 selector) are used in combination with
  525.    the multicast group address assigned to the Internet to form the
  526.    media address when forwarding a datagram with the multicast enable
  527.    option from a router to an attached network provided that the
  528.    datagram was not received on that network with either multicast or
  529.    broadcast media addressing. A host may send a multicast datagram
  530.    either to the media multicast address (the IP catenet model,) or
  531.    media unicast to a router which is expected to repeat it to the
  532.    multicast address within the entire level I area or to repeat copies
  533.    to the appropriate end systems within the area on non-broadcast media
  534.    (the more general CLNP model.)
  535.  
  536. Network Layer Translation
  537.  
  538.    The objective of translation is to be able to upgrade systems, both
  539.    hosts and routers, in whatever order desired by their owners.
  540.    Organizations must be able to upgrade any given system without
  541.    reconfiguration or modification of any other, and existing hosts must
  542.    be able to interoperate essentially forever. (Non-CATNIP routers will
  543.    probably be effectively eliminated at some point, except where they
  544.    exist in their own remote or isolated corners.)
  545.  
  546.    Each CATNIP system, whether host or router, must be able to recognize
  547.    adjacent systems in the topology that are (only) IP version 4, CLNP,
  548.    or IPX and call the appropriate translation routine just before
  549.    sending the datagram.
  550.  
  551. OSI CNLP
  552.  
  553.    The translation between CLNP and the CATNIP compressed form of the
  554.    datagrams is the simplest case for CATNIP, since the addresses are
  555.    the same and need not be extended. The resulting CATNIP datagrams may
  556.    omit the source and destination addresses as explained previously,
  557.    and may be mixed with uncompressed datagrams on the same subnetwork
  558.    link. Alternatively, a subnetwork may operate entirely in the CATNIP,
  559.  
  560.  
  561.  
  562. McGovern & Ullmann                                             [Page 10]
  563.  
  564. RFC 1707                         CATNIP                     October 1994
  565.  
  566.  
  567.    converting all transit traffic to CATNIP datagrams, even if FCIs that
  568.    would make the compression effective are not available.
  569.  
  570.    Similarly, all network datagram formats with CATNIP mappings may be
  571.    compressed into the common form, providing a uniform transit network
  572.    service, with common routing protocols (such as IS-IS).
  573.  
  574. Internet Protocol
  575.  
  576.    All existing version 4 numbers are defined as belonging to the
  577.    Internet by using a new AFI, to be assigned to IANA by the ISO. This
  578.    document uses 192 at present for clarity in examples; it is to be
  579.    replaced with the assigned AFI. The AFI specifies that the IDI is two
  580.    bytes long, containing an administrative domain number.
  581.  
  582.    The AD (Administrative Domain), identifies an administration which
  583.    may be an international authority (such as the existing InterNIC), a
  584.    national administration, or a large multi-organization (e.g., a
  585.    government). The idea is that there should not be more than a few
  586.    hundred of these at first, and eventually thousands or tens of
  587.    thousands at most.
  588.  
  589.    AD numbers are assigned by IANA. Initially, the only assignment is
  590.    the number 0.0, assigned to the InterNIC, encompassing the entire
  591.    existing version 4 Internet.
  592.  
  593.    The mapping from/to version 4 IP addresses:
  594.  
  595.       +----------+----------+---------------+---------------------+
  596.       |  length  |   AFI    |  IDI ...      | DSP ...             |
  597.       +----------+----------+---------------+---------------------+
  598.       |     7    |   192    |  AD number    | version 4 address   |
  599.       +----------+----------+---------------+---------------------+
  600.  
  601.    While the address (DSP) is initially always the 4 byte, version 4
  602.    address, it can be extended to arbitrary levels of subnetting within
  603.    the existing Internet numbering plan. Hosts with DSPs longer than 4
  604.    bytes will not be able to interoperate with version 4 hosts.
  605.  
  606. Novell IPX
  607.  
  608.    The Internetwork Packet Exchange protocol, developed by Novell based
  609.    on the XNS protocol (Xerox Network System) has many of the same
  610.    capabilities as the Internet and OSI protocols. At first look, it
  611.    appears to confuse the network and transport layers, as IPX includes
  612.    both the network layer service and the user datagram service of the
  613.    transport layer, while SPX (sequenced packet exchange) includes the
  614.    IPX network layer and provides service similar to TCP or TP4. This
  615.  
  616.  
  617.  
  618. McGovern & Ullmann                                             [Page 11]
  619.  
  620. RFC 1707                         CATNIP                     October 1994
  621.  
  622.  
  623.    turns out to be mostly a matter of the naming and ordering of fields
  624.    in the packets, rather than any architectural difference.
  625.  
  626.    IPX uses a 32-bit LAN network number, implicitly concatenated with
  627.    the 48-bit MAC layer address to form an Internet address. Initially,
  628.    the network numbers were not assigned by any central authority, and
  629.    thus were not useful for inter-organizational traffic without
  630.    substantial prior arrangement. There is now an authority established
  631.    by Novell to assign unique 32-bit numbers and blocks of numbers to
  632.    organizations that desire inter-organization networking with the IPX
  633.    protocol.
  634.  
  635.    The Novell/IPX numbering plan uses an ICD, to be assigned, to
  636.    designate an address as an IPX address. This means Novell uses the
  637.    authority (AFI=47)(ICD=Novell) and delegates assignments of the
  638.    following 32 bits.
  639.  
  640.    An IPX address in the common form looks like:
  641.  
  642.       +----------+----------+---------------+---------------------+
  643.       |  length  |   AFI    |  IDI ...      | DSP ...             |
  644.       +----------+----------+---------------+---------------------+
  645.       |    13    | 47 (hex) |  Novell ICD   | network+MAC address |
  646.       +----------+----------+---------------+---------------------+
  647.  
  648.    This will always be followed by two bytes of zero padding when it
  649.    appears in a common network layer datagram. Note that the socket
  650.    numbers included in the native form IPX address are part of the
  651.    transport layer.
  652.  
  653. SIPP
  654.  
  655.    It may seem a little odd to describe the interaction with SIPP-16
  656.    (version 6 of IP) which is another proposed candidate for the next
  657.    generation of network layer protocols. However, if SIPP-16 is
  658.    deployed, whether or not as the protocol of choice for replacement of
  659.    IP version 4, there will then be four network protocols to
  660.    accommodate.  It is prudent to investigate how SIPP-16 could then be
  661.    integrated into the common addressing plan and datagram format.
  662.  
  663.    SIPP-16 defines 128 bit addresses, which are included in the NSAP
  664.    addressing plan under the Internet AFI as AD number 0.1. It is not
  665.    clear at this time what administration will hold the authority for
  666.    the SIPP-16 numbering plan. This produces a 20 byte NSAPA, with the
  667.    system ID field positioned exactly as expected by (e.g.) IS-IS.
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. McGovern & Ullmann                                             [Page 12]
  675.  
  676. RFC 1707                         CATNIP                     October 1994
  677.  
  678.  
  679.       +----------+----------+---------------+---------------------+
  680.       |  length  |   AFI    |  IDI ...      | DSP ...             |
  681.       +----------+----------+---------------+---------------------+
  682.       |    19    |   192    |  AD (0.1)     |   SIPP-16 address   |
  683.       +----------+----------+---------------+---------------------+
  684.  
  685.    The SIPP-16 addressing method (the definition of the 128 bits) will
  686.    not be described here.
  687.  
  688.    The SIPP proposal also includes an encapsulated-tunnel proposal
  689.    called IPAE, to address some of the issues that are designed into
  690.    CATNIP.  The CATNIP direct translation does not use the SIPP-IPAE
  691.    packet formats. IPAE also specifies a "mapping table" for prefixes.
  692.    This table is kept up-to-date by periodic FTP transfers from a
  693.    "central site." The CATNIP definitions leave the problem of prefix
  694.    selection when converting into SIPP firmly within the scope of the
  695.    SIPP-IPAE proposal, and possible methods are not described here.
  696.  
  697.    In translating from SIPP (IPv6) to CATNIP (IPv7), the only unusual
  698.    aspect is that SIPP defines some things that are normally considered
  699.    options to be "payloads" overloaded onto the transport protocol
  700.    numbering space.  Fortunately, the only one that need be considered
  701.    is fragmentation; a fragmented SIPP datagram may need to be
  702.    reassembled prior to conversion.  Other "payloads" such as routing
  703.    are ignored (translated verbatim) and will normally simply fail to
  704.    achieve the desired effect.
  705.  
  706.    Translation to SIPP is simple, except for the difficult problem of
  707.    inventing the "prefix" if an implementation wants to support
  708.    translating Internet AD 0.0 numbers into the SIPP addressing domain.
  709.  
  710. Internet DNS
  711.  
  712.    CATNIP addresses are represented in the DNS with the NSAP RR. The
  713.    data in the resource record is the NSAP, including the zero selector
  714.    at the end. The zone file syntax for the data is a string of
  715.    hexadecimal digits, with a period "." inserted between any two octets
  716.    where desired for readability. For example:
  717.  
  718.    The inverse (PTR) zone is .NSAP.INT, with the CATNIP address
  719.    (reversed).  That is, like .IN-ADDR.ARPA, but with .NSAP.INT instead.
  720.    The nibbles are represented as hexadecimal digits.
  721.  
  722.    This respects the difference in actual authority: the IANA is the
  723.    authority for the entire space rooted in .IN-ADDR.ARPA. in the
  724.    version 4 Internet, while in the new Internet it holds the authority
  725.    only for 0.C.NSAP.INT. (Following the example of 192 as the AFI
  726.    value.) The domain 0.0.0.0.0.C.NSAP.INT is to be delegated by IANA to
  727.  
  728.  
  729.  
  730. McGovern & Ullmann                                             [Page 13]
  731.  
  732. RFC 1707                         CATNIP                     October 1994
  733.  
  734.  
  735.    the InterNIC. (Understanding that in present practice the InterNIC is
  736.    the operator of the authoritative root.)
  737.  
  738. Security Considerations
  739.  
  740.    The CATNIP design permits the direct use of the present proposals for
  741.    network layer security being developed in the IPSEC WG of the IETF.
  742.    There are a number of detailed requirements; the most relevant being
  743.    that network layer datagram translation must not affect (cannot
  744.    affect) the transport layers, since the TPDU is mostly inaccessible
  745.    to the router. For example, the translation into IPX will only work
  746.    if the port numbers are shadowed into the plaintext security header.
  747.  
  748. References
  749.  
  750.    [Chapin93]      Chapin, L., and D. Piscitello, "Open Systems
  751.                    Networking", Addison-Wesley, Reading, Massachusetts,
  752.                    1993.
  753.  
  754.    [Perlman92]     Perlman, R., "Interconnections: Bridges and Routers"
  755.                    Addison-Wesley, Reading, Massachusetts, 1992.
  756.  
  757.    [RFC791]        Postel, J., Editor, "Internet Protocol - DARPA
  758.                    Internet Program Protocol Specification", STD 5, RFC
  759.                    791 USC/Information Sciences Institute,  September
  760.                    1981.
  761.  
  762.    [RFC792]        Postel, J., Editor, "Internet Control Message
  763.                    Protocol - DARPA Internet Program Protocol
  764.                    Specification", STD 5, RFC 792, USC/Information
  765.                    Sciences Institute, September 1981.
  766.  
  767.    [RFC793]        Postel, J., Editor, "Transmission Control Protocol -
  768.                    DARPA Internet Program Protocol Specification,
  769.                    STD 7, RFC 793, USC/Information Sciences Institute,
  770.                    September, 1981.
  771.  
  772.    [RFC801]        Postel, J., "NCP/TCP Transition Plan", RFC 801,
  773.                    USC/Information Sciences Institute, November, 1981.
  774.  
  775.    [RFC1191]       Mogul, J., and S. Deering, "Path MTU Discovery",
  776.                    RFC 1191, DECWRL, Stanford University, November,
  777.                    1990.
  778.  
  779.    [RFC1234]       Provan, D., "Tunneling IPX Traffic Through IP
  780.                    Networks", RFC 1234, Novell, Inc., June 1991.
  781.  
  782.  
  783.  
  784.  
  785.  
  786. McGovern & Ullmann                                             [Page 14]
  787.  
  788. RFC 1707                         CATNIP                     October 1994
  789.  
  790.  
  791.    [RFC1247]       Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc.,
  792.                    July 1991.
  793.  
  794.    [RFC1287]       Clark, D., Chapin, L., Cerf, V., Braden, R., and
  795.                    R. Hobby, "Towards the Future Internet Architecture",
  796.                    RFC 1287, MIT, BBN, CNRI, ISI, UCDavis, December,
  797.                    1991.
  798.  
  799.    [RFC1335]       Wang, Z., and J. Crowcroft, "A Two-Tier Address
  800.                    Structure for the Internet: A Solution to the
  801.                    Problem of Address Space Exhaustion", RFC 1335,
  802.                    University College London, May 1992.
  803.  
  804.    [RFC1338]       Fuller, V., Li, T., Yu, J., and K. Varadhan,
  805.                    "Supernetting: an Address Assignment and Aggregation
  806.                    Strategy", RFC 1338, BAARNet, cicso, Merit, OARnet,
  807.                    June 1992.
  808.  
  809.    [RFC1347]       Callon, R., "TCP and UDP with Bigger Addresses
  810.                    (TUBA), A Simple Proposal for Internet Addressing
  811.                    and Routing", RFC 1347, DEC, June 1992.
  812.  
  813.    [RFC1466]       Gerich, E., "Guidelines for Management of IP Address
  814.                    Space", RFC 1466, Merit, May 1993.
  815.  
  816.    [RFC1475]       Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
  817.                    Process Software Corporation, June 1993.
  818.  
  819.    [RFC1476]       Ullmann, R., "RAP: Internet Route Access Protocol",
  820.                    RFC 1476, Process Software Corporation, June 1993.
  821.  
  822.    [RFC1561]       Piscitello, D., "Use of ISO CLNP in TUBA
  823.                    Environments", RFC 1561, Core Competence, December
  824.                    1993.
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. McGovern & Ullmann                                             [Page 15]
  843.  
  844. RFC 1707                         CATNIP                     October 1994
  845.  
  846.  
  847. Authors' Addresses
  848.  
  849.    Michael McGovern
  850.    Sunspot Graphics
  851.  
  852.    EMail: scrivner@world.std.com
  853.  
  854.  
  855.    Robert Ullmann
  856.    Lotus Development Corporation
  857.    1 Rogers Street
  858.    Cambridge, MA 02142
  859.  
  860.    Phone: +1 617 693 1315
  861.    EMail: rullmann@crd.lotus.com
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. McGovern & Ullmann                                             [Page 16]
  899.  
  900.