rfc1707.txt

RFC 的详细文档！

   While the address (DSP) is initially always the 4 byte, version 4
   address, it can be extended to arbitrary levels of subnetting within
   the existing Internet numbering plan. Hosts with DSPs longer than 4
   bytes will not be able to interoperate with version 4 hosts.

Novell IPX

   The Internetwork Packet Exchange protocol, developed by Novell based
   on the XNS protocol (Xerox Network System) has many of the same
   capabilities as the Internet and OSI protocols. At first look, it
   appears to confuse the network and transport layers, as IPX includes
   both the network layer service and the user datagram service of the
   transport layer, while SPX (sequenced packet exchange) includes the
   IPX network layer and provides service similar to TCP or TP4. This



McGovern & Ullmann                                             [Page 11]

RFC 1707                         CATNIP                     October 1994


   turns out to be mostly a matter of the naming and ordering of fields
   in the packets, rather than any architectural difference.

   IPX uses a 32-bit LAN network number, implicitly concatenated with
   the 48-bit MAC layer address to form an Internet address. Initially,
   the network numbers were not assigned by any central authority, and
   thus were not useful for inter-organizational traffic without
   substantial prior arrangement. There is now an authority established
   by Novell to assign unique 32-bit numbers and blocks of numbers to
   organizations that desire inter-organization networking with the IPX
   protocol.

   The Novell/IPX numbering plan uses an ICD, to be assigned, to
   designate an address as an IPX address. This means Novell uses the
   authority (AFI=47)(ICD=Novell) and delegates assignments of the
   following 32 bits.

   An IPX address in the common form looks like:

      +----------+----------+---------------+---------------------+
      |  length  |   AFI    |  IDI ...      | DSP ...             |
      +----------+----------+---------------+---------------------+
      |    13    | 47 (hex) |  Novell ICD   | network+MAC address |
      +----------+----------+---------------+---------------------+

   This will always be followed by two bytes of zero padding when it
   appears in a common network layer datagram. Note that the socket
   numbers included in the native form IPX address are part of the
   transport layer.

SIPP

   It may seem a little odd to describe the interaction with SIPP-16
   (version 6 of IP) which is another proposed candidate for the next
   generation of network layer protocols. However, if SIPP-16 is
   deployed, whether or not as the protocol of choice for replacement of
   IP version 4, there will then be four network protocols to
   accommodate.  It is prudent to investigate how SIPP-16 could then be
   integrated into the common addressing plan and datagram format.

   SIPP-16 defines 128 bit addresses, which are included in the NSAP
   addressing plan under the Internet AFI as AD number 0.1. It is not
   clear at this time what administration will hold the authority for
   the SIPP-16 numbering plan. This produces a 20 byte NSAPA, with the
   system ID field positioned exactly as expected by (e.g.) IS-IS.






McGovern & Ullmann                                             [Page 12]

RFC 1707                         CATNIP                     October 1994


      +----------+----------+---------------+---------------------+
      |  length  |   AFI    |  IDI ...      | DSP ...             |
      +----------+----------+---------------+---------------------+
      |    19    |   192    |  AD (0.1)     |   SIPP-16 address   |
      +----------+----------+---------------+---------------------+

   The SIPP-16 addressing method (the definition of the 128 bits) will
   not be described here.

   The SIPP proposal also includes an encapsulated-tunnel proposal
   called IPAE, to address some of the issues that are designed into
   CATNIP.  The CATNIP direct translation does not use the SIPP-IPAE
   packet formats. IPAE also specifies a "mapping table" for prefixes.
   This table is kept up-to-date by periodic FTP transfers from a
   "central site." The CATNIP definitions leave the problem of prefix
   selection when converting into SIPP firmly within the scope of the
   SIPP-IPAE proposal, and possible methods are not described here.

   In translating from SIPP (IPv6) to CATNIP (IPv7), the only unusual
   aspect is that SIPP defines some things that are normally considered
   options to be "payloads" overloaded onto the transport protocol
   numbering space.  Fortunately, the only one that need be considered
   is fragmentation; a fragmented SIPP datagram may need to be
   reassembled prior to conversion.  Other "payloads" such as routing
   are ignored (translated verbatim) and will normally simply fail to
   achieve the desired effect.

   Translation to SIPP is simple, except for the difficult problem of
   inventing the "prefix" if an implementation wants to support
   translating Internet AD 0.0 numbers into the SIPP addressing domain.

Internet DNS

   CATNIP addresses are represented in the DNS with the NSAP RR. The
   data in the resource record is the NSAP, including the zero selector
   at the end. The zone file syntax for the data is a string of
   hexadecimal digits, with a period "." inserted between any two octets
   where desired for readability. For example:

   The inverse (PTR) zone is .NSAP.INT, with the CATNIP address
   (reversed).  That is, like .IN-ADDR.ARPA, but with .NSAP.INT instead.
   The nibbles are represented as hexadecimal digits.

   This respects the difference in actual authority: the IANA is the
   authority for the entire space rooted in .IN-ADDR.ARPA. in the
   version 4 Internet, while in the new Internet it holds the authority
   only for 0.C.NSAP.INT. (Following the example of 192 as the AFI
   value.) The domain 0.0.0.0.0.C.NSAP.INT is to be delegated by IANA to



McGovern & Ullmann                                             [Page 13]

RFC 1707                         CATNIP                     October 1994


   the InterNIC. (Understanding that in present practice the InterNIC is
   the operator of the authoritative root.)

Security Considerations

   The CATNIP design permits the direct use of the present proposals for
   network layer security being developed in the IPSEC WG of the IETF.
   There are a number of detailed requirements; the most relevant being
   that network layer datagram translation must not affect (cannot
   affect) the transport layers, since the TPDU is mostly inaccessible
   to the router. For example, the translation into IPX will only work
   if the port numbers are shadowed into the plaintext security header.

References

   [Chapin93]      Chapin, L., and D. Piscitello, "Open Systems
                   Networking", Addison-Wesley, Reading, Massachusetts,
                   1993.

   [Perlman92]     Perlman, R., "Interconnections: Bridges and Routers"
                   Addison-Wesley, Reading, Massachusetts, 1992.

   [RFC791]        Postel, J., Editor, "Internet Protocol - DARPA
                   Internet Program Protocol Specification", STD 5, RFC
                   791 USC/Information Sciences Institute,  September
                   1981.

   [RFC792]        Postel, J., Editor, "Internet Control Message
                   Protocol - DARPA Internet Program Protocol
                   Specification", STD 5, RFC 792, USC/Information
                   Sciences Institute, September 1981.

   [RFC793]        Postel, J., Editor, "Transmission Control Protocol -
                   DARPA Internet Program Protocol Specification,
                   STD 7, RFC 793, USC/Information Sciences Institute,
                   September, 1981.

   [RFC801]        Postel, J., "NCP/TCP Transition Plan", RFC 801,
                   USC/Information Sciences Institute, November, 1981.

   [RFC1191]       Mogul, J., and S. Deering, "Path MTU Discovery",
                   RFC 1191, DECWRL, Stanford University, November,
                   1990.

   [RFC1234]       Provan, D., "Tunneling IPX Traffic Through IP
                   Networks", RFC 1234, Novell, Inc., June 1991.





McGovern & Ullmann                                             [Page 14]

RFC 1707                         CATNIP                     October 1994


   [RFC1247]       Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc.,
                   July 1991.

   [RFC1287]       Clark, D., Chapin, L., Cerf, V., Braden, R., and
                   R. Hobby, "Towards the Future Internet Architecture",
                   RFC 1287, MIT, BBN, CNRI, ISI, UCDavis, December,
                   1991.

   [RFC1335]       Wang, Z., and J. Crowcroft, "A Two-Tier Address
                   Structure for the Internet: A Solution to the
                   Problem of Address Space Exhaustion", RFC 1335,
                   University College London, May 1992.

   [RFC1338]       Fuller, V., Li, T., Yu, J., and K. Varadhan,
                   "Supernetting: an Address Assignment and Aggregation
                   Strategy", RFC 1338, BAARNet, cicso, Merit, OARnet,
                   June 1992.

   [RFC1347]       Callon, R., "TCP and UDP with Bigger Addresses
                   (TUBA), A Simple Proposal for Internet Addressing
                   and Routing", RFC 1347, DEC, June 1992.

   [RFC1466]       Gerich, E., "Guidelines for Management of IP Address
                   Space", RFC 1466, Merit, May 1993.

   [RFC1475]       Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
                   Process Software Corporation, June 1993.

   [RFC1476]       Ullmann, R., "RAP: Internet Route Access Protocol",
                   RFC 1476, Process Software Corporation, June 1993.

   [RFC1561]       Piscitello, D., "Use of ISO CLNP in TUBA
                   Environments", RFC 1561, Core Competence, December
                   1993.

















McGovern & Ullmann                                             [Page 15]

RFC 1707                         CATNIP                     October 1994


Authors' Addresses

   Michael McGovern
   Sunspot Graphics

   EMail: [e-mail]


   Robert Ullmann
   Lotus Development Corporation
   1 Rogers Street
   Cambridge, MA 02142

   Phone: [phone]
   EMail: [e-mail]




































McGovern & Ullmann                                             [Page 16]