home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / catnip / catnip-minutes-94mar.txt < prev    next >
Text File  |  1994-05-13  |  8KB  |  167 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Robert Ullmann/Lotus Development Corporation
  5.  
  6. Minutes of the Common Architecture for Next-Generation IP (CATNIP)
  7.  
  8.  
  9. Introduction
  10.  
  11. The meeting was convened by Robert Ullmann, chair pro tempore, as
  12. Vladimir Sukonnik was unable to attend.  There were no additions to the
  13. announced agenda.
  14.  
  15. The initial presentation was a short soapbox by Robert Ullmann.  He
  16. stressed that CATNIP is solely a new network layer.  It does not
  17. initially change APIs, transports, the NSAP interfaces; it does not
  18. change the subnetwork access (e.g., ES-IS or ARP). New applications and
  19. protocol definitions can take advantage of the new range of addressing,
  20. but existing ones are undisturbed.  Other related technologies, such as
  21. network layer security, are (in the presenter's opinion) outside of the
  22. scope of IPng; the existing and future work in security and routing can
  23. be applied to any IPng as well as the existing protocols.
  24.  
  25.  
  26. Technical Issues
  27.  
  28. Technical points of discussion were divided roughly into two groups:
  29. first technical issues in CATNIP, and then points of difference with
  30. TUBA, with an objective of attaining exact alignment with TUBA on the
  31. common ground.
  32.  
  33. The first point was a discussion of translating fragments.  The data
  34. unit identifiers present some issues:  IPv4 and CLNP use 16-bit IDs,
  35. implicitly including source and destination; CATNIP uses 64-bit IDs with
  36. explicit identification of a fragmenting router.  Simply using the least
  37. significant 16 bits may be sufficient.  It was pointed out that
  38. differing semantics between IPv4, CLNP, and SIPP make translating
  39. fragments that originate in one to end up reassembled in another
  40. problematic; however it was also pointed out that the case of
  41. X!CATNIP!X for some existing protocol X was the important case, and
  42. could always be accomplished.
  43.  
  44. The TTL in ICMP cache setup messages should always be one, to ensure
  45. they only go to adjacent stations.
  46.  
  47. When converting TTL to and from the IPX count-up ``transport control''
  48. field, there are issues of scaling and the value of ``infinity'' in IPX;
  49. the proposed resolution was to increase the limit in IPX routers if
  50. possible.  No one present knew if this is configurable in existing
  51. implementations.
  52.  
  53. The format of IPX registered addresses was discussed, including the
  54. concept that the Novell registry be part of the formal authority
  55. delegation for global addresses.  An issue about the placement of
  56. fields, originally raised by Greg Minshall of Novell, was discussed,
  57. although Greg was not present.  Radia Perlman, also of Novell, noted
  58. that the block of IPX network numbers with the first 8 bits zero and
  59. last 24 bits equal to an IANA/InterNIC IPv4 network number are defined
  60. as registered in parallel to the same entity.
  61.  
  62. Local-use (unregistered) IPX network numbers are going to be supported
  63. by CATNIP; since they cannot be distinguished, this cannot be
  64. technically precluded.  (Presumably, local use IPv4 numbers as defined
  65. by RFC 1597 fall into the same category, although they could be
  66. recognized.)
  67.  
  68. The issue of the source NSEL in CLNP was raised:  should it be zero or a
  69. copy of the destination NSEL? The only technical argument seems to be
  70. that a native OSI CLNP system expects to be able to reverse source and
  71. destination addresses, and there seems to be no reason not to
  72. accommodate this.  The tentative conclusion is that CATNIP and TUBA
  73. should be aligned on specifying that source is a copy of destination.
  74.  
  75. The next issue discussed was the coverage of the addresses by the TCP
  76. and UDP checksums.  CATNIP specifies that the checksum uses only the
  77. last four bytes of the NSAPA (not including NSEL), which is where the
  78. IPv4 address is when interoperating; when those bytes are part of some
  79. ID, possibly copied from an 802 address, the check is still pretty good.
  80. It was pointed out that this is not as good as covering the entire
  81. address, as in the current TUBA specification.  However, that requires
  82. that systems doing translation ``adjust'' the transport checksum; this
  83. is impossible with the NLSP in use, and breaks the premise of an
  84. end-to-end checksum, even if done incrementally, as the addresses may
  85. have been already mis-mapped, and the intermediate system would then
  86. helpfully ``fix'' the checksum.  This item is to be returned to the TUBA
  87. Working Group, with a suggestion that TUBA be modified.
  88.  
  89. Addressing plans were discussed, with Robert Ullmann observing that the
  90. existence of the NSAPA guidelines for the Internet, together with the
  91. CATNIP defined mapped areas, and the other OSI plans, did not present a
  92. conflict.  Time, and much actual use, would resolve which were the most
  93. useful, with the new Internet using some combination of existing and
  94. future plans at any given point.
  95.  
  96. Richard Colella presented the current state of the DNS work to define an
  97. NSAP resource record, and take the necessary administrative actions to
  98. define a reverse zone for mapping NSAPAs to Internet names.  It was
  99. agreed that although there were aesthetic issues, there were no hard
  100. technical issues remaining, and that CATNIP (and probably TUBA) would
  101. use the result.  It was pointed out that previous DNS definitions have
  102. not been put on the standards track, since the components are
  103. administrative assignments by IANA; possibly this can be simply issued
  104. as an Informational RFC documenting the assignments.
  105.  
  106. There were no additional questions, and the meeting was adjourned.
  107.  
  108.  
  109. Attendees
  110.  
  111.  
  112. Garrett Alexander        gda@tycho.ncsc.mil
  113. Ron Aley                 aley@cac.washington.edu
  114. Mark Allyn               allyn@netcom.com
  115. Steven Andersen          scanders@mhs.sp.paramax.com
  116. Vadim Antonov            avg@sprint.net
  117. Richard Binder           rbinder@cnri.reston.va.us
  118. Scott Bradner            sob@harvard.edu
  119. Dick Brooks              d.brooks@ieee.org
  120. Jerry Burchfield         burchfiel@bbn.com
  121. John Burruss             jburruss@wellfleet.com
  122. Frank Cannata            cannata@cabletron.com
  123. Brian Carpenter          brian@dxcoms.cern.ch
  124. Richard Colella          colella@nist.gov
  125. Alex Conta               conta@lassie.lkg.dec.com
  126. Richard Cornetti         cornetti@wg.com
  127. Stephen Deering          deering@parc.xerox.com
  128. Robert Elz               kre@mulga.cs.mu.oz.au
  129. H. Tom Fitzpatrick       fitz@ddn.af.mil
  130. Eric Fleischman          ericf@atc.boeing.com
  131. Robert Frankston
  132. Robert Gilligan          Bob.Gilligan@Eng.Sun.Com
  133. William Haggerty         haggerty@ctron.com
  134. Denise Heagerty          denise@dxcoms.cern.ch
  135. Jack Houldsworth         J.Houldsworth@ste0906.wins.icl.co.uk
  136. Richard Hovey            hovey@silkie.enet.dec.com
  137. Phil Irey                pirey@relay.nswc.navy.mil
  138. John Larson              jlarson@parc.xerox.com
  139. Fong-Ching Liaw          fong@eng.sun.com
  140. Tracy Mallory            tracym@3com.com
  141. J. Scott Marcus          smarcus@bbn.com
  142. Michael Massa            mikemas@microsoft.com
  143. Marjo Mercado            marjo@cup.hp.com
  144. Keith Moore              moore@cs.utk.edu
  145. Kim Morla                kmorla@pucp.edu.pe
  146. Phil Nesser              pjnesser@rocket.com
  147. Peder Chr.  Noergaard    pcn@tbit.dk
  148. Erik Nordmark            nordmark@eng.sun.com
  149. Krishnan Parameshwaran   krishnap@microsoft.com
  150. James Philippou          japhilippou@eng.xyplex.com
  151. David Piscitello         dave@corecom.com
  152. Steven Russert           srussert@atc.boeing.com
  153. Sibylle Schaller         schaller@ibmpa.awdpa.ibm.com
  154. Steven Schnell           schnell@sprintlink.net
  155. Jay Smith                jaysmith@us.oracle.com
  156. Barbara Sterling         bjs@mcdata.com
  157. John Tavs                tavs@vnet.ibm.com
  158. Richard Thomas           rjthomas@bnr.ca
  159. Wendell Turner           wt@arinc.com
  160. Robert Ullmann           rullmann@crd.lotus.com
  161. Willem van der Scheun    scheun@sara.nl
  162. Gary Veum                veum@boa.gsfc.nasa.gov
  163. William Warner           warner@ohio.gov
  164. Geoff White              geoff@nexsys.net
  165. Jeff Young               jsy@cray.com
  166.  
  167.