INTERIM_MEETING_REPORT_


Reported by Dave Crocker/TBO

Minutes of the IP Address Encapsulation Working Group (IPAE)

This meeting took place on August 27, 1992 via Videoconference and was,
essentially, a review session for a number of issues.  The one item
which was pursued further was a report from Steve Deering about
Addressing.

Administrivia

Copies of the current versions of the specifications, Craig Partidge's
BSD diffs, and a few other files are now at PARC.

Mike Conn, of MCI, has very gratiously offered to provide a
teleconferencing bridge (telephone) for future meetings.  This will
allow those not able to go to a videoconferencing site to participate
over the phone.

Addressing (Steve Deering)

Discussion about Geographic-based addressing has gone in the direction
of allowing Provider-based addressing _also]_, to handle the early
stages of the new addressing plan.  It appears that to remain strictly
geographic will require very considerable complexity inside the datagram
routing service, since metropolitan areas are, in no way, guaranteed to
have inter-vendor transfer sites (now dubbed `Metropolitan Internet
Exchange' or ``MIX''.)

There is a need to ensure that the primary addressing authority is
independent of any provider.

There is also a continuing concern that the MIX concept requires sharing
of customer information between competitors.  They is the retort that
that information is discernible anyhow.

Discussions will continue.  Next Addressing meeting will be September
11th.

Side note:  The Group feels that the specifications need to be crystal
clear about the philosophy that is driving their choices, to facilitate
evaluation among the different proposals.

ACTION: (Crocker) upgrade specs to emphasize end-user friendly and
installed base friendly intent of IPAE.

There is intended to be support for ``multi-homed'' commonwealths.  That
is, a host may have more than one commonwealth ID. This might facilitate
transition issues, such as from vendor-oriented addressing to
geographic, but it still requires the ability to add and delete
addresses.  The question of the way to propagate such information is

                                   1





still open.

IPAE Options

At the previous meeting, the question of providing space for IPAE-level
options was discussed and rejected.  At this meeting, we reviewed the
decision, with no one suggesting it be reversed.

IPAE Border Router Discovery

This was another review topic.  In general, most of the techniques that
are used to discover an IP first-hop router can be re-used to discover
the IPAE first-hop (i.e., border) router.  But John Moy suggested use of
a fixed, logical address, written into the IPAE spec.  This could then
trigger an IPAE-ICMP Redirect, when a logical border router gets the
first IPAE datagram.

A concern was raised that this scheme would have trouble if the user
datagram is fragmented, along the way to the border router, and worse,
the fragments traveled to different logical border routers.  The
conclusion was that fragmentation is relatively rare and this is
yet-another strong vote for MTU Discovery.  Further, multiple
destinations occurs only due to path-splitting or a transient problem.
The former is something that can be limited, for the logical address,
and the latter is ``only'' a transient problem.

Miscellaneous

ACTION: (Crocker) The spec needs to better detail the behavior of the
_exit_ border routers (the last IPAE hop before the destination host.)
More protocol mechanics.

ACTION: (Crocker) Spec should give an example of address handling, as
IPAE datagram moves through the Internet.

ICMP

Sigh.

IPAE intends to permit permanent support for unmodified routers, within
a commonwealth.  This means that routers will be generating current
(old- style) ICMP message, which means ICMP messages without the full
(IPAE, global) addresses of the originating host whose action triggered
the ICMP datagram.  The exit border router (last hop before the router
generating the ICMP) has the task of turning the ICMP into an IPAE
datagram.

But it can't do that if it does not have the full global address of the
originating host.

Only three options seem available:


  1. Seek to have routers upgraded to generate larger ICMP datagrams, so

                                   2





     that they will include the IPAE header from the originating host.

  2. Have the Border router throw away ICMPs that it can't convert

  3. Have the Border router perform some sort of record-keeping of IPAE
     datagrams, so that it can match the returned 64-bits with a full
     IPAE global address.


The Group discussed these options.  After appropriate (and large)
amounts of illness-feeling, it was agreed that no other options seem to
exist and all of the listed options were terrible.  Options 1 and 2 seem
like the most constructive and practical, with option 3 unlikely.

ACTION: (Champlin) Survey existing router behavior, to determine the
size of ICMP datagrams they actually generate, to determine if the
theoretical problem is real.

ACTION: (Crocker) Verify Host Requirements statements about ICMP size.

ACTION: (Crocker) Add relevant text to Spec (not Transition doc) about
this issue, including reasonable options.



                                   3