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