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