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 >
Wrap
Text File
|
1994-05-13
|
8KB
|
167 lines
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