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