Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/pip/pip-minutes-93jul.txt

Text File | 1993-09-16 | 13KB | 296 lines

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              [e-mail]
Bernt Allonen            [e-mail]
Frederik Andersen        [e-mail]
Per Andersson            [e-mail]
Michael Anello           [e-mail]
Anders Baardsgaad        [e-mail]
John Ballard             [e-mail]
Nutan Behki              [e-mail]
Per Bilse                [e-mail]
Jim Binkley              [e-mail]
Robert Blokzijl          [e-mail]
Ronald Broersma          [e-mail]
Steve Buchko             [e-mail]
John Burnett             [e-mail]
Ross Callon              [e-mail]
Brian Carpenter          [e-mail]
George Clapp             [e-mail]
David Conrad             [e-mail]
Geert Jan de Groot       [e-mail]
Stephen Deering          [e-mail]
Kurt Dobbins             [e-mail]
Ian Duncan               [e-mail]
Kjeld Borch Egevang      [e-mail]

                                   4





Dino Farinacci           [e-mail]
Stefan Fassbender        [e-mail]
Dennis Ferguson          [e-mail]
Eric Fleischman          [e-mail]
Peter Ford               [e-mail]
Osten Franberg           [e-mail]
Paul Francis             [e-mail]
Shoji Fukutomi           [e-mail]
Eugene Geer              [e-mail]
Robert Gilligan          [e-mail]
Joseph Godsil            [e-mail]
Ramesh Govindan          [e-mail]
Joel Halpern             [e-mail]
Jari Hamalainen          [e-mail]
John Hopkins             [e-mail]
Chris Howard             [e-mail]
Christian Huitema        [e-mail]
Geoff Huston             [e-mail]
David Jacobson           [e-mail]
Cyndi Jung               [e-mail]
Scott Kaplan             [e-mail]
Frank Kastenholz         [e-mail]
Dave Katz                [e-mail]
Peter Kaufmann           [e-mail]
Ton Koelman              [e-mail]
John Krawczyk            [e-mail]
Tony Li                  [e-mail]
Robin Littlefield        [e-mail]
Greg Minshall            [e-mail]
Keith Mitchell           [e-mail]
Peder Chr.  Noergaard    [e-mail]
Erik Nordmark            [e-mail]
Michael O'Dell           [e-mail]
Petri Ojala              [e-mail]
Michael Patton           [e-mail]
David Piscitello         [e-mail]
Luc Rooijakkers          [e-mail]
Henry Sanders            [e-mail]
W. David Sincoskie       [e-mail]
Henk Steenman            [e-mail]
Vladimir Sukonnik        [e-mail]
Richard Thomas           [e-mail]
Susan Thomson            [e-mail]
Hisao Uose               [e-mail]
Willem van der Scheun    [e-mail]
Werner Vogels            [e-mail]
Scott Wasson             [e-mail]
Jost Weinmiller          [e-mail]
Kirk Williams            [e-mail]
Sam Wilson               [e-mail]
Noriko Yokokawa          [e-mail]
Jessica Yu               [e-mail]
Romeo Zwart              [e-mail]


                                   5