CURRENT_MEETING_REPORT_ Reported by Christian Huitema/INRIA Minutes of the Simple Internet Protocol Working Group (SIP) The SIP Working Group met Tuesday morning and Wednesday afternoon. The Tuesday session was devoted to the finalization of the SIP specification, specially in light of the first interoperability experiences. The Wednesday session was devoted to the analysis of routing protocols. SIP Specification The first speaker in the session was Steve Deering, who reviewed the recent ``precisions'' to the SIP specification: o The first 32 flow-ids values have been ``reserved'' for IP ``TOS'' compatibility. o The formats for the LSR and reassembly payloads has been slightly modified, so that the ``payload type'' arrives first. o The payload type 0 has been reserved for hop by hop options. Routers are supposed to inspect the payload type of every packets. If this type is set to zero, then ``hop by hop'' options should be examined. A generic format for hop by hop has been defined: after a generic ``option header'' expressing the embedded payload type and the number of 64 bit words used to carry the option, each hop by hop option is represented by a set of 32 bit words; the first octets include the option type and the option length, expressed as a number of 32 bit words. There was a discussion on the adequacy of using the 32 bit words units, and a proposal to use a byte count instead; the Working Group turned this down, and reached consensus on 32 bit word count. Steve then presented the requirements for ``option ordering''. To sum up, it is required to have the following order in the packets: o Sip header o Hop by hop option, if present o Source route option, if present o Fragmentation header, if present o Data Then, Steve presented a change in terminology: ``Cluster address'' instead of ``anyone'' address. The Working Group noted the requirement for two precisions in the specifications: 1 1. Multicast addresses cannot be used in source routes. 2. Cluster addresses should never be used as source addresses. This implies that cluster addresses should not be used for TCP connections, as they cannot be used as ``reply'' addresses. Steve also mentioned that the new specification will include precisions on the ``pseudo checksum computation'' (e.g., for ICMP and IGMP), in particular when the ``C'' bit is set. IEEE-802 Address Format The discussion switched then to the definition of an IEEE-802 address format. Steve Deering and Bob Hinden presented a format where a SIP address can be build by prepending a 16 bit header to an IEEE-802 48 bit address. ------------------------------------ | prfx | Subnet | IEEE-802 address | ------------------------------------ The 16 bit prefix, in this proposition, is divided in two fields, a 6 bit prefix for recognizing this address as an IEEE-802 address, and a 10 bit ``subnet identifier'' to identify the ``local network'' to which the station is connected. This triggered a discussion on the usage of this addresses and the proper length for the prefix and subnet field, with the following conclusions: o These addresses should only be used as long as no ``real SIP'' address has been assigned to the station. o They should never be advertized outside of the ``autonomous system'', i.e. through IDRP. o The prefix should be 8 bit long, and the subnet also 8 bit. The need to study the interaction with the DNS was also mentioned. Security Labelling The last speaker in Tuesday's session was Randy Atkinson, who had submitted a ``SIPSO'' draft, describing a ``security labeling'' option, and also presented the various possibilities for designing an end-to-end security option based on SP-3 and NLSP. The discussion of the labeling option was marked by the following comments: o The main rationale for the labeling proposal was ``compatibility with IPv4''. Some IPv4 routers used in ``secure environment'' use 2 the labeling service, and would suffer from ``reduced capabilities'' if the function was not available. o It was pointed out that security label alone were not very useful and that security should be addressed ``globally'', e.g. also in the routing architecture. o Randy Atkinson mentioned that one rationale for the labeling option was also to prevent negative feelings, e.g. propagation of the false impression that SIP would be more ``insecure'' than IPv4 because it would be missing the option. In fact, all members agreed that end-to-end security was much more important. Randy continued his presentation by explaining how SP-3 is used to encapsulate and protect IP packets. It was decided to track the IPv4 efforts on the subject, and to come out with a SIP version of their proposal as soon as the IPv4 drafts stabilize. Session 2 The first point on the Agenda of the Wednesday session was the review of the ``DNS for SIP'' draft. The draft defines an ``AA'' type record for storing the 64 bit SIP addresses, and a reverse tree under ``sip-addr.arpa''. It was decided after discussions to align the format of the reverse addresses with the ``standard'' external format of SIP addresses. The name corresponding to the SIP address: 0abc:f120:138.96.24.84 will be obtained through the inverse domain name: 84.24.96.138.f120.abc.sip-addr.arpa The SIP-DNS Draft will be updated accordingly. SIP Version of Three Routing Protocols The next part of the session was devoted to the study of the ``SIP'' version of three routing protocols, RIP, OSPF and IDRP. o The SIP-RIP draft was presented by Gary Malkin. The draft is derived from RIP-2, with the following modifications: - Addresses are 64 bit, 3 - Bit masks are contiguous, - The metric is designed to converge on the best throughput, instead of the lesser number of hops. Gary presented then three possible amendments to SIP-RIP, proposed by himself and Yakov Rekhter: 1. As the SIP routers can easily now the MTU ofterface on which a RIP packet is transmitted, there is no need for a standard 576 length limit -- they can as well make packets as big as the MTU allows. 2. By using an algorithm suggested by () and by () in the 1989 SIGCOM conference, it is possible to remove the ``bouncing effect'' and to compute loop free routes. The cost is to add one extra address information per routing entry, and one computation step before propagating routes. 3. By using the ``route on demand'' improvement suggested in a draft by ?? After discussion, it was decided that modification (1) and (2) should be incorporated in the current draft, and that (3), which represent a substantial although compatible improvement, should be specified in a separate document. o The SIP-OSPF Draft was presented by Christian Huitema. The main features of the Draft are: - Regular OSPF, running over IPv4 - Two additional LSAs to import SIP information and an additional bit in the router-LSA to indicate SIP capability. - ``Integrated routing'' in order to ease the migration from IPv4 to SIP, after which a native OSPF for SIP would be defined. A number of points were raised: - The IPv4 address to use when tunneling should be that of the selected interface to the dual SIP/IPv4 host. There should be a way to identify this interface address. - The translation between SIP and IPv4 formats should only take place in border routers. - We should avoid doing ``double transition''. The specification should be definitive. - We should specify clearly whether ``SIP'' areas are requested to have the same boundaries as ``IPv4'' areas. - When defining new LSAs, we should perhaps be able to specify a ``multiprotocol'' format. 4 It was decided that all detailed discussions of OSPF in SIP would be carried on in the SIP Working Group. o The IDRP for SIP draft written by Sue Hares was presented by Yakov Rekhter. Options for representing SIP addresses and for identifying SIP ``autonomous systems'' were discussed, as well as the need to define a document for multicast routing. Bill Simpson presented the provisional results of the working party on ES/IS, ARP and autoconfiguration. Attendees Kannan Alagappan kannan@dsmail.lkg.dec.com Guy Almes almes@ans.net Michael Anello mike@xlnt.com Randall Atkinson atkinson@itd.nrl.navy.mil David Battle battle@cs.utk.edu Tom Benkart teb@acc.com Fred Bohle fab@interlink.com David Bolen db3l@ans.net Erik-Jan Bos erik-jan.bos@surfnet.nl Robert Braden braden@isi.edu Monroe Bridges monroe@cup.hp.com David Bridgham dab@epilogue.com Al Broscius broscius@bellcore.com Jeff Carman tcarman@bnr.ca Kevin Carosso kvc@innosoft.com David Carr Carr@acsu.buffalo.edu John Chang jrc@uswest.com Rob Coltun rcoltun@ni.umd.edu Steve Deering deering@parc.xerox.com Osmund DeSouza osmund.desouza@att.com Chas DiFatta chas@cmu.edu Ralph Droms droms@bucknell.edu David Dubois dad@pacersoft.com Pierre Dupont dupont@mdd.comm.mot.com Tom Easterday tom@cic.net Dino Farinacci dino@cisco.com Dennis Ferguson dennis@ans.net Eric Fleischman ericf@act.boeing.com Paul Francis Francis@thumper.bellcore.com Peter Furniss p.furniss@ulcc.ac.uk John Gawf gawf@compatible.com Joseph Godsil jgodsil@ncsa.uiuc.edu Ramesh Govindan rxg@thumper.bellcore.com Danny Hanson hanson.tic@commlan.safb.af.mil John Hascall john@iastate.edu Robert Hinden hinden@eng.sun.com Jeffrey Honig Jeffrey_C_Honig@Cornell.edu Steven Hubert hubert@cac.washington.edu Christian Huitema christian.huitema@sophia.inria.fr 5 John Ioannidis ji@cs.columbia.edu Phil Irey pirey@relay.nswc.navy.mil Ronald Jacoby rj@sgi.com David Johnson dbj@cs.cmu.edu Laurent Joncheray lpj@merit.edu Dan Jordt danj@nwnet.net Doug Karl dkarl@osu.edu Kenneth Key key@cs.utk.edu Charley Kline cvk@uiuc.edu Moshe Kochinski moshek@FibHaifa.com Mark Laubach laubach@hpl.hp.com Mark Lewis Mark.S.Lewis@telebit.com Yu-Lin Lu yulin@hpinddu.cup.hp.com Paul Lustgraaf grpjl@iastate.edu Charles Lynn clynn@bbn.com Bruce Mackey brucem@cinops.xerox.com Carl Madison carl@startek.com Gary Malkin gmalkin@xylogics.com David Meyer meyer@ns.uoregon.edu Greg Minshall minshall@wc.novell.com Matthew Morrisey morrisey@wpsp01.hq.aflc.af.mil John Moy jmoy@proteon.com Erik Nordmark nordmark@eng.sun.com William Owens owens@acsu.buffalo.edu Michael Patton map@bbn.com Gaige Paulsen gaige@intercon.com John Penners jpenners@advtech.uswest.com Willi Porten porten@gmd.de David Reese dave@csu.net Yakov Rekhter yakov@watson.ibm.com Manoel Rodrigues manoel_rodrigues@att.com Yzhak Ronen y.ronen@homxa.att.com William Simpson Bill.Simpson@um.cc.umich.edu Subbu Subramaniam subbu@cup.hp.com Terry Sullivan terrys@newbridge.com Fumio Teraoka tera@csl.sony.co.jp Kamlesh Tewani ktt@arch2.att.com Richard Thomas rjthomas@bnr.ca Susan Thomson set@bellcore.com L. Stuart Vance vance@tgv.com John Veizades veizades@apple.com Dinesh Verma verma@watson.ibm.com Warren Vik wmv@lachman.com Ruediger Volk rv@informatik.uni-dortmund.de Chuck Warlick warlick@theophilis.nsfc.nasa.gov Scott Wasson sgwasson@eng.xyplex.com Von Welch vwelch@ncsa.uiuc.edu Fred Whiteside fred@bws.com Steven Willis steve@wellfleet.com Richard Woundy rwoundy@vnet.ibm.com Charles Young Charles.E.Young@att.com 6