CURRENT_MEETING_REPORT_ Reported by Robert Hinden/Sun Microsystems Minutes of the Joint Sessions of the SIP and PIP Working Groups These minutes are based on the notes taken by Christian Huitema and Bob Hinden. The Simple Internet Protocol Working Group (SIP) and the P. Internet Protocol Working Group held two joint sessions. The first session was on Monday, November 1. The second session was held on November 4. Both sessions were carried on the Internet Multicast. The agenda distributed prior to the meeting was reviewed and updated for the meeting. SIPP Merger Overview (Steve Deering) The purpose of the merger is to keep the simplicity and transition features of SIP and the advanced routing capabilities of Pip---while making them easier to use and to understand. The mailing lists have been merged, and Bob Hinden is writing a charter for the merged group. This has resulted in some changes in the specifications, and in some terminologies. The changed terms are: SIP --> SIPP system --> node anyone address --> cluster address Source route header --> Routing header The new terminology: o The uniqueness scope of an address; for example the uniqueness scope of the loopback address is just one single node. o The routing scope of an address, which is generally global to the Internet, but can sometimes be restricted e.g., for a ``local use address.'' Routing scope is always less than uniqueness scope, but not necessarily equal to it. SIPP Overview and Issues (Steve Deering) The address semantics have changed. Addresses identify nodes or set of nodes, not interfaces. A node may have several addresses, which may, in some instances, be tied to an interface. The packet format has not changed, except for the ``reserved'' field which is now called ``flow label.'' The 64-bit addresses are still composed of an IP address and a 32-bit prefix. The 64-bit SIPP address space is 10 million times larger than the global telephone number space. The address formats are: - classic: prefix, customer ID, node ID. ----------------------------------------- |c| provider ID | customer ID | node ID | ----------------------------------------- - cluster: ----------------------------------------- |c| provider ID | 0...................0 | ----------------------------------------- - local use address: ----------------------------------------- | 0..0 | subnet | IEEE 802 address | ----------------------------------------- - multicast address: ----------------------------------------- | 1..1 | flags + | group ID | | | scope | | ----------------------------------------- The addresses are ``provider oriented.'' The current SIP addressing drafts are obsolete. New SIPP versions will be submitted. Options are encoded as a sequence of headers. SIPP options currently defined are fragmentation, routing and hop-by-hop options. Options for end-to-end security and flow set-up are under development. Options are not limited to 40 bytes like IP. The format of the routing header is: -------------------------------------------- | Payload | Number of | Next | Reserved | | | Addresses | Address | | -------------------------------------------- | Reserved | | | -------------------------------------------- | | + Address[0] + | | -------------------------------------------- | | + Address[1] + | | -------------------------------------------- | | . . . .... . . . | | -------------------------------------------- | | + Address[n] + | | -------------------------------------------- The minimum packet length has not changed. The routing header uses 64-bit chunks rather than the 16-bit chunks of Pip. Paul Francis mentioned that the advantage of this approach was ``simplicity of handling.'' The addresses have their own routing scope, which relieves the need for the ``routing contexts'' which were present in Pip. Noel Chiappa observes that the routing header is more traditional source routing rather than Pip ``flows.'' Paul Francis said this was incorrect and that the Pip routing was not intended as flows. The 28 bits of the flow-label will be structured according to one of two possible formats: ---------------------------------------- | DP | 0 | TOS| ---------------------------------------- ---------------------------------------- | DP | flow-ID | ---------------------------------------- o 4 bits of ``drop priority'' o 4-bit TOS is traditional IP type of service o 24-bit flow-ID is a pseudo random number chosen by source to identify special flow state along path The reason that the flow-ID is random, based on an idea from Dave Clark, is that it makes it easy to use a subset of it (bit slice) as a ``hash code'' for access to a flow table within the routers. To a question on TOS, it is observed that this really is a heritage from IPv4, although current experience in IPv4 networks is rather bleak. There was considerable discussion leading to the suggestion to drop IPv4 TOS. SIPP Routing and Addressing (Paul Francis, Ramesh Govindan) Paul Francis presented the use of the routing header. All packets are identified with 64-bit addresses which are unique with the scope, but may need additional 64-bit addresses to complement an insufficient routing scope. There is also a need for mobile hosts, or when special policies are required. The SIPP addresses are contiguous bit-wise maskable (similar to IP with CIDR). This poses conditions for extended addresses: o Single hierarchy element cannot straddle 64-bit boundary. o Top and bottom 64 bits have to be both globally unique; one could perhaps release this requirement for ``middle'' addresses. Currently SIPP assumes hierarchical provider addresses. The cluster address is similar to an ``anycast address,'' i.e., it addresses any of the routers sharing a prefix. If a packet arrives from ``outside,'' it is accepted by the first node that matches the prefix; if from within the node, it is accepted by the first router that operates at ``that prefix length.'' In the current state of the art, they will have to be ``hand configured.'' Examples of such addresses are: o Provider.0: accepted by first router in provider network, used for provider selection. o Provider.subnet.0: can be used for mobility support. The local use addresses provide an 8-bit fixed prefix and an 8-bit ``subnet number'' in complement to the 48-bit IEEE-802 address. The local use addresses can be used over a multi-subnet site. It could be used exclusively for a site not connected to the Internet. The address sequence has to be ``manipulated'' by the hosts. This is really what the merger with Pip is all about. Note that the SIPP header format did not change in the merger. Hosts should be able to: o Represent their own address as a sequence, not just a single 64-bit address. o Reverse an address sequence. If hosts do this from the start, new semantics can be added to the Internet, for example extended addresses, without having to update any internet hosts. The group mentions that there should be a minimum size specification, e.g., ``at least three components.'' This applies to local configuration, nodes should be able to process arbitrarily long routing headers. Similarly, a limit is needed for DNS configuration (size of record) and for ``reverse look up'' in the DNS (depth of the tree). Also, the ``error behavior'' should be specified -- what should be done if the host receives a packet that it cannot understand. Paul then presented the literal notation for the source route mechanism: . Two kinds of address sequence have been defined: source capable and not source capable. For example, a multicast address is not ``source capable'': it cannot be used as a source address in a packet. Suppose a sequence , i.e., the source chain then the destination chain. In most cases the chain will have exactly two elements . This was only true in Pip for local communications. Paul presented the mechanism for building and reversing source routes, and mentioned the open issue: whether routes should be stored in the internet program, in the transport or in the application. Ramesh Govindan presented different examples of sophisticated routing using the SIPP routing header. This included: o Basic routing involving only the DNS. Sequence has two elements, reversal is trivial. o Selection of the first hop provider. Sequence has three elements; change of provider within the association life time is easy. o Item with ``extended addresses,'' with four elements in the sequence. o Examples are also given for multicast, including source routing prior to multicasting. o Multicast is also possible with extended addresses: this allows recipients to reply to the source address. o Mobility examples are also given: the address sequence includes the identification of the ``base station.'' Note that the ``mobile cluster'' scenario is not presented! Address extension can also be used for auto-configuration: 1. Hosts creates a ``local wire'' address. 2. Host will receive a local cluster address, e.g., by receiving advertisement. It can combine his hardware address with this prefix, to form either a 64-bit address if the prefix is short enough, or an extended address otherwise. Several members of the group question the ``automatic reversal'' of source routes in the case of ``provider selection.'' There are clearly several degrees of liberty at this stage. IPAE Specification Overview and Issues (Bob Gilligan/Erik Nordmark) A new specification has been written by Bob Gilligan, Erik Nordmark and Bob Hinden. This is based on the original specification by Dave Crocker, and one year of work and discussion. The components of the specification are: o Encapsulation within IPv4 for ``tunnelling.'' o 64-bit SIPP addressing scheme is compatible with IPv4 plan: 6 6 3 3 0 3 2 2 1 0 +---+-------------+--------------+ | c | Site Prefix | IPv4 address | +---+-------------+--------------+ The ``c'' bit explains whether the host is SIPP capable or not. o Host algorithms for direct interoperability with IPv4 hosts. o Translation agent between SIPP and IPv4. Bill Simpson questioned the change of vocabulary from ``commonwealth'' to ``site''---as commonwealth implied a larger kind of object. Steve Deering believes no name for these objects is really needed. Christian Huitema noted the need for a conventional 32-bit prefix, removing the need for ``mapping tables'' as long as hosts are capable of IP routing. John Curran mentioned the relation between site table and provider IDs: if one changes provider, then one changes prefixes, thus one has to change the ``mapping table.'' The upper 32 bits carry an assumption about provider connectivity. The picture has changed a lot since the advent of CIDR; if CIDR really solves the routing table explosion, then the ``mapping table'' is not necessary. As Steve Deering mentions, the group really hates the mapping tables. Jim Bound mentioned the complexity of transition for a host, and suggested that the group emphasize the inherent simplicity of the 64-bit approach. A list of remaining IPAE issues came out when revising the specification. o How do translators set the IPv4 ID field when doing SIPP to IPv4 translation? One idea was to keep a counter for IDs, another to put a hash function, a third to use a pseudo random generator. o What to do with the TOS field? Should it map to SIPP TOS/Channel-ID? There is no general consensus. Dave Clark supports that TOS are complementary to channel IDs, which may lead to revisit the specification versus TOS and Drop preferences. o How should translators handle IPv4 packets with the DF bit set? Erik Nordmark shows the following scenarios: ____________________________________________ |_Ipv4_Source__SIPP____________IPv4_________| | | | DF not set Fragment to 576 copy ID | | incl frag head DF not set | | | |_DF_set_______No_frag_header__DF_set,_ID=0_| ___________________________________________ |_SIPP_source____IPv4______________________| | | | Frag header Copy ID field | | DF not set | | | | No frag header Generate pseudo unique ID | |________________DF_not_set_______________ | This last case is ugly. One could in fact mandate the presence of the fragmentation header whenever a SIPP host sends a packet to an IPv4 host. The ``c'' bit in the source address mentions the real source, but using it is not very elegant. So, the decision is to correct the last case to: ________________________________ |_SIPP_source____IPv4___________| | | | Frag header Copy ID field | | DF not set | | | | No frag header Generate ID = 0| |________________DF_set_________| This implies that the rules for MTU discovery have to be changed. If a host receives a ``packet too long'' ICMP with a length lower than the minimum length, then it should send the next packet with the fragment header! The group agreed to this. o Should IPAE hosts be required to do path MTU discovery on their tunnels? Steve Deering explains that the MTU can sometimes be lower than the 576 minimum, which will imply using fragmentation. The idea is that MTU discovery should be recommended, but still optional. o ICMP checksum: using a different checksum for IP and SIPP version of ICMP is really a pain. The consensus was that correctness is more important than the complexity in this case. Erik Nordmark presented the problems of keeping state when ``tunnelling'' is used: o ICMP packet too big: Need to memorize the tunnel MTU, for either immediate transcription. o ICMP TTL exceeded: Need to memorize the tunnels TTL, o ICMP ``unreachable'': Signals an incorrect tunnel. These ``states'' should really be ``soft state,'' i.e., updated cautiously. The SIPP design helps the error handling, as the initial hop limit was present in the first bytes of the packet. This helps computing the ``exact length'' of the tunnel. The state can be discarded for garbage collection (reduce the memory requirement) and also for detecting improvements -- for example if a remote router suddenly becomes reachable. The MTU increases will regularly be probed by the source, so the absence of remote ICMP may be an indication of the absence of problem. Neighbor Discovery/ARP (Bill Simpson) The protocol has been renamed ``neighbor discovery'' after the merging. It has two packets: ``where are you'' stating the address looked for, and ``I am here,'' with variable parameters. All packets include a ``media type'' and ``MAC address'' parameter, so that one does not need ARP. Bill questioned the need for further usage of the ``change prefix'' parameter, which is used to broadcast ``changes of providers.'' This is now well done, with prefix length, old address and new address. Another questioned feature was the passing of information about other routers and other subnets---use discovery as a router protocol, or at least as a replacement for ``OSPF hellos.'' The particular format of this ``routing information'' is hotly debated; in particular it is suggested to separate information on the router address and information on the ``connected subnets.'' For each subnet, there are ``preferences'' and ``priority,'' as well as a ``zone'' used for local addresses, and ``MRU'' indicating the maximum packet length used by the routers. The utility of several fields, or even the very utility of this parameter, is debated: o MRU is generally understood as ``not needed.'' o The parameters taken from OSPF and IS-IS should go away. o ``Zone'' is an inappropriate name for ``local scope subnets,'' which should just be passed as particular subnets. The ``system heard'' parameter is essential for support of eliminating the ``hidden transmitter'' problem. For each system heard, this pass various parameters: quality of reception, advertisement number, etc. This seems too complex to many listeners. Steve Deering requested the removal of the ``service advertisements.'' Bill also presented ``transit informations'' and ``redirects.'' Further discussion is clearly needed! SIPP OSPF (Rob Coltun) Rob proposes the acronym ``OSPPF'': bigger addresses, more protocols. For carrying big addresses, one needs to: o Provide ``link state ID'' independent of address. Currently, an LSA is identified by [Router ID, LS-ID], where LS-ID represents the ``network number.'' A 32-bit locally unique ID will be used in OSPPF. o Advertisement will have to carry long address in addition to LS-ID. The schema of the LSA is: ---------------------- | Advertising router | ---------------------- | Link State ID | ---------------------- | Type | ---------------------- | | | Address | | | ---------------------- | Router ID | ---------------------- | ... | ---------------------- There is agreement that the ``advertising router'' should be a 64-bit field; in general, routers should be identified by their 64-bit identifying address. The LSA is identified by the combination of advertising router and LS-ID; the LS-ID has to be unique within the router, i.e. can be a random 32-bit number. It is not even necessary to keep the same number during different ``instantiations,'' e.g., after a reboot, as the old segments will either be replaced or fade away. Indeed, this implies that the LS-ID cannot be overloaded. For the big addresses, one has to carry a length field (in bytes) and the number of significant bits; thus it makes sense to also carry a ``type'' field, which enables for running other protocols in parallel: ----------------------------- | Type | Len | Mask size | ----------------------------- | Address | ----------------------------- | | ----------------------------- The ``type'' field is used to specify e.g., IP or SIPP, which means that OSPPF has dual protocol capability. Rob then addressed the ``hierarchical'' problem. Two levels are probably enough (200 routers per area imply 40,000 routers). It is easy to do a multiple level version, e.g., to accommodate regionals which want to integrate their clients as OSPF areas, and also because inter domain routing requires a lot of work. There is however a general agreement that such developments should be discussed in the OSPF group, and that the SIPP version should really be a straight forward transcription of OSPF to 64-bit addresses. SIPP Service Interfaces and DNS Changes (Sue Thomson) Sue Thompson presented the changes to the DNS for storing address sequences and for supporting the transition. These are: o A new ``ASEQ'' record, a sequence of 64-bit elements, which does not cause additional processing. o A new ``inverse look-up name,'' which was defined similarly to that of the initial SIP, and used a PTR query. There is however a consensus on a ``per octet'' break up that seems more rational given the ``bit mask'' nature of the address. This will be represented as a sequence of hex tokens, without leading zeros. Jim Bound would like the DNS interfaces to strip the upper parts of the address sequence when they are not necessary. This will have to be specified in the routing architecture. There are two transition issues: 1. Whether resolvers should return A records if no ASEQ address is present. According to Sue, resolvers will have to ask for both ASEQ and A. 2. Whether the additional section should only include A records, or also ASEQ records. Decision is that if the query is received from a SIPP host, then ASEQ should also be returned. Sue is going to implement the specification in bind 4.9. Auto Configuration and DHCP (Jim Bound) The DHCP protocol is very straightforward. DHCP is sitting in the application layer, so has to traverse the entire stack; after a simple ``connection'' exchange, the client is returned a set of configuration information, e.g., an address. In some cases, databases have to be updated. Steve Deering mentioned that dynamic updates of the DNS are not really required; one might as well preallocate name and address types. John Wroklavski mentioned that auto-configuration is the ``single most important'' design part of IPng; it should work in a large set of environments. Jim Bound mentioned that DHCP can really be used without problem, and that making a SIPP option is really straightforward. Ohta asked whether SIPP/DHCP will have ``relay agents.'' In fact, we don't need them as SIPP stations can very easily use a hardware address. Thus, the group will be able to use multicast to find the DHCP server, including with diameters larger than 1 (outside the local net): there is no need for relays, routers do the job easily. Paul Francis proposed to write a specific document explaining how network layer mechanisms can be used to help auto-configuration, but also for discovering DNS servers, gopher servers, etc. Jim insisted that we have to be concerned by automatic configuration of the DNS, i.e., register automatically IP address and DNS name bindings. Jim Bound will prepare a ``64-bit'' version of DHCP. Address Assignment Issues (Paul Francis) Given the difficulties of managing geographic addresses, there is agreement that only ``provider'' addresses should be used in the short term. The immediate assignment is: ----------------------------- |1| 31 bits | 32 bits | |C| something | IP address | ----------------------------- Detail of IP address under CIDR: ----------------------------------------------------- | Provider ID | Subscriber ID | subnet ID | Node ID | ----------------------------------------------------- Without CIDR, the address is: ----------------------------------------------------- | network number | subnet ID | Node ID | ----------------------------------------------------- These addresses will be a ``legacy'' of the pre-CIDR era. Provider, subscriber, subnet and host is a good hierarchy; but eventually growth will force us beyond 32 bits. Thus, at least the provider ID should be pushed into the higher 31 bits of the SIPP address. The proposal is to: o Push provider part in upper 31 bits. o Leave room below provider for subscriber and ``subProvider'' parts. o Leave room above provider ID for contingencies. This gives the following structure: -------------------------------------------------------------- | 8 bits | 24 bits | m bits | p bits | 32-m-p | -------------------------------------------------------------- | C 0..0 | provider Id | subscriber Id | subnet ID | Node ID | -------------------------------------------------------------- The provider ID will be assigned ``from the left,'' which means that they are followed by a number of zeros, which allow for future growth of the ``subscriber ID'' part. There was a general consensus to proceed with this plan for address assignment. Attendees Kenneth Albanese albanese@icp.net Steve Alexander stevea@lachman.com James Allard jallard@microsoft.com Susie Armstrong susie@mentat.com Randall Atkinson atkinson@itd.nrl.navy.mil Anders Baardsgaard anders@cc.uit.no William Barns barns@gateway.mitre.org Stephen Batsell batsell@itd.nrl.navy.mil Nutan Behki nebhki@newbridge.com Steven Bellovin smb@research.att.com Tom Benkart teb@acc.com Ram Bhide ram@nat.com Erik-Jan Bos erik-jan.bos@surfnet.nl Jim Bound bound@zk3.dec.com Scott Bradner sob@harvard.edu Monroe Bridges monroe@cup.hp.com Ronald Broersma ron@nosc.mil Al Broscius broscius@bellcore.com Ross Callon rcallon@wellfleet.com Peter Cameron cameron@xylint.co.uk George Chang gkc@ctt.bellcore.com David Conrad davidc@iij.ad.jp Matt Crawford crawdad@fncent.fnal.gov John Curran jcurran@nic.near.net Michael Davis mike@dss.com Chuck de Sostoa chuckd@cup.hp.com Stephen Deering deering@parc.xerox.com Avri Doria avri@locus.com Donald Eastlake dee@skidrow.lkg.dec.com Havard Eidnes havard.eidnes@runit.sintef.no Robert Enger enger@seka.reston.ans.net Roger Fajman raf@cu.nih.gov Stefan Fassbender stf@easi.net Carlos Fernandez carlos@plk.af.mil Eric Fleischman ericf@atc.boeing.com Richard Fox rfox@metricom.com Paul Francis Francis@thumper.bellcore.com Atanu Ghosh atanu@cs.ucl.ac.uk Robert Gilligan Bob.Gilligan@Eng.Sun.Com Ramesh Govindan rxg@thumper.bellcore.com Jari Hamalainen jah@rctre.nokia.com Herluf Hansen hha@tbit.dk Dimitry Haskin dhaskin@wellfleet.com Marc Hasson marc@mentat.com Robert Hinden hinden@eng.sun.com Kathy Huber khuber@wellfleet.com Christian Huitema Christian.Huitema@sophia.inria.fr Phil Irey pirey@relay.nswc.navy.mil Kevin Jackson kjackson@concord.com Ronald Jacoby rj@sgi.com Dale Johnson dsj@merit.edu Timo Jokiaho timo.jokiaho@ntc.nokia.com Rick Jones raj@cup.hp.com Akira Kato kato@wide.ad.jp Elizabeth Kaufman kaufman@biomded.med.yale.edu Hiroshi Kawazoe kawazoe@trl.ibm.co.jp Edwin King eek@atc.boeing.com Andrew Knutsen andrewk@sco.com John Krawczyk jkrawczy@wellfleet.com Tony Li tli@cisco.com Kanchei Loa loa@sps.mot.com Allison Mankin mankin@cmf.nrl.navy.mil Peram Marimuthu peram@wg.com Greg Minshall minshall@wc.novell.com Randy Miyazaki randy@lantron.com Andrew Myles andrew@mpce.mg.edu.au Rina Nathaniel rina@rnd-gate.rad.co.il Sath Nelakonda sath@lachman.com Erik Nordmark nordmark@eng.sun.com Masataka Ohta mohta@cc.titech.ac.jp Steve Parker sparker@ossi.com Ismat Pasha ipasha@icm1.icp.net Michael Patton map@bbn.com Charles Perkins perk@watson.ibm.com Eric Peterson elpeterson@eng.xyplex.com Benny Rodrig brodrig@rnd-gate.rad.co.il Michal Rozenthal michal@fibronics.co.il Dallas Scott scott@fluky.mitre.org Isil Sebuktekin isil@nevin.bellcore.com Vincent Shekher vin@sps.mot.com Ming Sheu msheu@vnet.ibm.com William Simpson Bill.Simpson@um.cc.umich.edu Frank Solensky solensky@ftp.com James Solomon solomon@comm.mot.com Tae Song tae@novell.com Michael Speer michael.speer@sun.com Vladimir Sukonnik sukonnik@process.com Steve Suzuki steve@fet.com Susan Thomson set@bellcore.com Akihiro Tominaga tomy@sfc.wide.ad.jp Thuan Tran thuan@xylogics.com Hoe Trinh htrinh@vnet.ibm.com Keisuke Uehara kei@cs.uec.ac.jp Chuck Warlick chuck.warlick@pscni.nasa.gov Chris Wheeler cwheeler@cac.washington.edu Walter Wimer walter.wimer@andrew.cmu.edu Jane Wojcik jwojcik@bbn.com David Woodgate David.Woodgate@its.csiro.au Liang Wu ltwu@bellcore.com Jean Yao yao@cup.hp.com Shinichi Yoshida yoshida@sumitomo.com Jessica Yu jyy@merit.edu Weiping Zhao zhao@nacsis.ac.jp