CURRENT_MEETING_REPORT_ Reported by Geoff Huston/Australian Academic and Research Network Minutes of the P. Internet Protocol Working Group (PIP) Overview A specification overview was presented to the attendees. The specification of forwarding has remained unchanged for the past 3 months. The DNS architecture to support PIP has been revised. The PIP identifier structure has been revised. IDRP routing support for PIP has revisions in progress. The host operations specifications has been revised. The PIP Control Message Protocol is new, and is currently incomplete. The PIP transition specification is new. Missing from the specification is a MIB definition. Routing still requires further definition. PIP Progress o PIP DNS The use of the DNS as a support tool for PIP transition is still under review. The major new area of support functionality required is that of timestamped queries, as described in the PIP DNS specification. In addition, the use of the DNS in PIP transition is described in the PIP transition specification. o PIP IDS The hierarchical structure of PIP identifiers has been weakened, and a flat ID structure is considered sufficient while allowing simple integration of auto-configuration mechanisms. The ID structure is that of a 2-byte identifier prefix and a 6-byte static host identifier. It was noted that there were questionable returns for a richer identifier structuring. It was noted that within the current specification of PIP there was no visible requirement for reverse lookups based on PIP IDs to discover PIP addresses, on the basis that PIP IDs and PIP addresses are intended to be passed together. Further structuring of the PIP host identifiers was left as an open issue. o PIP Routing Routing is based on a multilevel path vector, coupled with IDRP as the routing framework. The basic algorithms for PIP routing are essentially complete, but anycast, tunnelling and Quality of Service attributes have yet to be implemented. IDRP is used as a mechanism to support neighbour reachability and sequencing. o PIP Transition 1 Evaluation of transition arrangements using IPAE and an IP Independent Transition structure have been undertaken. The meeting focussed on this topic in further detail. o PIP Host Operations The host will be required to perform a choice of multiple PIP addresses, within the context of two hosts performing an address choice which allows optimal end-to-end reachability. The host operations include heuristics for host address selection and the use of PCMP messages in order to instruct the host to select an alternative address. o PCMP Currently PCMP has support for ``packet not delivered'' with 12 reasons. Other PCMP types, including router discovery mechanisms, are to be specified. IP to PIP Transition Concerns were expressed with the IPAE approach as an answer to the transition problem. The meeting reviewed an alternative approach to transition using a translating boundary architecture, the IP Independent Transition (IPIT) approach. In evaluating the usefulness of IPAE it was noted that the use of IP addresses within an IPng packet allowed packet header translation in the direction of IPng to IP to be relatively straightforward. The packet header translation in the direction of IP to IPng does require an inverse lookup in order to generate the IPng address from the destination IP address. The static nature of this lookup does have negative implications where support for auto-configuration and mobility is desired within the transitioning environment. The IPIT approach uses a translational approach where the binding of an IP address to an IPng host is dynamic, and the binding is undertaken by the boundary translating router. The nature of the binding (static/dynamic reuse) is reliant of the relative size of the pool of bindable IP addresses and the number of IPng hosts. The participants noted that this approach did have application layer implications where applications included explicit description of network layer addresses. The participants also noted that there was a requirement for the host to regularly inform the translating router that the IP address is in use, and also explicitly inform the router when the address can be returned to the pool for subsequent rebinding to another IPng host. The meeting explored various scenarios of pool allocation, as they related to packet header translation. The meeting noted that various operational practices, such as support of end-to-end traceroute will imply extensive use of the pool with a requirement for careful management of binding structures of IP addresses within the IPng domain. SNMP management from the IP domain of IPng resources was also discussed, with the outcome that management within an IPng domain would be from within the domain. 2 The objective of IPIT is to use dynamic binding of IP addresses to IPng hosts in order to ensure that transition can use a smaller set of IP addresses than a static binding would imply. Pool size can be further reduced by using the IPng/translation IP address pair as the translation table index, allowing different IPng hosts be assigned the same translational IP address (under a set of specific conditions). Experimentation with IPIT was proposed, on the basis that if major operational flaws were exposed through this approach, the IPAE structure could be used as a fallback. The participants discussed the topic of whether early or late partitioning was considered desirable, and the dinosaur argument was proposed, where the view was expressed that extensive transitional structures designed to provide an unnatural extension of life for retrograde hosts were considered to be a unnatural practice. The event sequence for the binding of an IP address to an IPng host was examined. It was noted that the use of the DNS in the process of choice of a translating router implied that initial IP address binding from the pool was performed without explicit knowledge of the IP domain end host, and that the state requirements within the translating router, coupled with the requirement for DNS sequences, did imply fate-sharing on the basis of a requirement for synchronisation of the operation of the DNS and the translating routers. The translating routers also form a critical single point of failure within the IPIT structure. The participants also discussed the bootstrap phase for the setup of the DNS forwarding across the IP/IPng domain boundary, and it was noted that IPng DNS servers would require a permanent IP address binding which was known to all boundary routers. The role and configuration of IPng DNS servers within this context was discussed. PIP support for provider selection as a component of the transitional environment was discussed, and the use of reversal of an IP source route was considered, with the overall conclusion that provider selection would not map across the IP/IPng boundary within the transition environment. DNS Operations DNS operations within the PIP environment were presented at the meeting. The DNS operation requires the introduction of a new PIP class. The PIP ID is to be stored as an A RR, and the PIP address as ADDR RRs. The function of IP inverse lookup domain is supported within the PIP DNS environment as reverse domains for ID and address to map to domain names, and a third domain to map from ID to address. The role of the DNS within IPIT was discussed, and it was noted that there was a requirement during transition for the PIP domain to be supported within an incomplete domain space within the PIP class. This implies that recursive resolvers must determine whether NSs are defined 3 within the PIP class, which also implies that stub resolvers within the transitional environment will be inefficient. The inclusion of support for timestamped queries was discussed, with a motivation that PIP addresses are more likely to change in response to provider changes, and a mechanism for effectively specifying a request for more recent information from the DNS was required. It was noted that timestamp queries are more widely applicable, and that this function is on the DNS Working Group agenda for consideration. This is documented in the pip-dns Internet-Draft. Deployment The parts of PIP deployment which have been completed are the host code, the forwarding engine, PIP to IP translation and IP to PIP translation, encapsulation, P-ARP and PCMP. In addition pconf has been written as a configuration generator, which takes a network specification and generates specific configuration descriptions. An experimental deployment on the PIP Backbone on 20 hosts across the Internet has been completed. Future plans focus on deployment across further hosts and routers. Attendees Nick Alfano alfano@mpr.ca Bernt Allonen bal@tip.net Frederik Andersen fha@dde.dk Per Andersson pa@cdg.chalmers.se Michael Anello mike@xlnt.com Anders Baardsgaad anders@cc.uit.no John Ballard jballard@microsoft.com Nutan Behki Nutan_Behki@qmail.newbridge.com Per Bilse bilse@ic.dk Jim Binkley jrb@ibeam.intel.com Robert Blokzijl K13@nikhef.nl Ronald Broersma ron@nosc.mil Steve Buchko stevebu@newbridge.com John Burnett jlb@adaptive.com Ross Callon rcallon@wellfleet.com Brian Carpenter brian@dxcern.cern.ch George Clapp clapp@ameris.center.il.ameritech.com David Conrad davidc@iij.ad.jp Geert Jan de Groot geertj@ica.philips.nl Stephen Deering deering@parc.xerox.com Kurt Dobbins dobbins@ctron.com Ian Duncan id@cc.mcgill.ca Kjeld Borch Egevang kbe@craycom.dk 4 Dino Farinacci dino@cisco.com Stefan Fassbender stf@easi.net Dennis Ferguson dennis@ans.net Eric Fleischman ericf@act.boeing.com Peter Ford peter@goshawk.lanl.gov Osten Franberg euaokf@eua.ericsson.se Paul Francis Francis@thumper.bellcore.com Shoji Fukutomi fuku@furukawa.co.jp Eugene Geer ewg@cc.bellcore.com Robert Gilligan Bob.Gilligan@Eng.Sun.Com Joseph Godsil jgodsil@ncsa.uiuc.edu Ramesh Govindan rxg@thumper.bellcore.com Joel Halpern jmh@network.com Jari Hamalainen jah@rctre.nokia.com John Hopkins J_Hopkins@icrf.icnet.uk Chris Howard chris_howard@inmarsat.org Christian Huitema Christian.Huitema@sophia.inria.fr Geoff Huston g.huston@aarnet.edu.au David Jacobson dnjake@vnet.ibm.com Cyndi Jung cmj@3com.com Scott Kaplan scott@wco.ftp.com Frank Kastenholz kasten@ftp.com Dave Katz dkatz@cisco.com Peter Kaufmann kaufmann@dfn.dbp.de Ton Koelman koelman@stc.nato.int John Krawczyk jkrawczy@wellfleet.com Tony Li tli@cisco.com Robin Littlefield robin@wellfleet.com Greg Minshall minshall@wc.novell.com Keith Mitchell keith@pipex.net Peder Chr. Noergaard pcn@tbit.dk Erik Nordmark nordmark@eng.sun.com Michael O'Dell mo@uunet.uu.net Petri Ojala ojala@eunet.fi Michael Patton map@bbn.com David Piscitello dave@mail.bellcore.com Luc Rooijakkers lwj@cs.kun.nl Henry Sanders henrysa@microsoft.com W. David Sincoskie sincos@thumper.bellcore.com Henk Steenman henk@sara.nl Vladimir Sukonnik sukonnik@process.com Richard Thomas rjthomas@bnr.ca Susan Thomson set@bellcore.com Hisao Uose uose@tnlab.ntt.jp Willem van der Scheun scheun@sara.nl Werner Vogels werner@inesc.pt Scott Wasson sgwasson@eng.xyplex.com Jost Weinmiller jost@prz.tu-berlin.d400.de Kirk Williams kirk@sbctri.sbc.com Sam Wilson sam.wilson@ed.ac.uk Noriko Yokokawa norinori@wide.ad.jp Jessica Yu jyy@merit.edu Romeo Zwart romeo@sara.nl 5