INTERIM_MEETING_REPORT_ Reported by Dave Crocker/TBO Minutes of the IP Address Encapsulation Working Group (IPAE) This meeting was held at Sun Microsystems on October 8, 1992 The major topic of the meeting has been documented in a note sent by Bob Hinden, concerning a change to the IPAE header, to make it be the same as the SIP header. (i.e., make IPAE = IP+SIP, plus transition rules.) This was a somewhat unexpected turn of events, except in hindsight. A number of forces seem to have been moving us in this direction and there was a very strong feeling, by the end of the meeting, that this change vastly cleans up the entire scenario for the Internet, giving it the least transition pain and the most amenable longer-term protocol, since it is the closest to current IP AND it has a mechanism for adding new services (via its own mini-layer.) Reminder: SIP has a mailing list. To join, send to: sip-request@caldera.usc.edu Two other items were covered: ICMP The 64-bit data limit for ICMP continues to be a problem. We discussed more about the handling of ICMP messages sent by interior, unmodified routers, which therefore contain only the within-commonwealth IP addresses of the interior router and the border IPAE router and don't have the full IPAE address of the originating host available. We had generally believed that this was an unfortunate, but not serious, problem. It was then observed that it _is_ a significant problem for MTU Discovery. The originating host really does need to get the ICMP feedback. We adopted the framework that a commonwealth which does IPAE/IP tunneling -- i.e., the interior routers are not IPAE knowledgeable -- can be viewed much the same as IP over X.25, with the border routers treating the commonwealth as an underlying data-link environment. Hence, feedback from interior routers is like feedback from interior X.25 packet switches. We would not expect those raw messages to be forwarded back to the originating host. We would expect the border routers to record the feedback and translate it. In this case, this means that the border router needs to cache MTU information about IP addresses inside its commonwealth. When it gets an IPAE datagram, it needs to check its size against the cache (cache = dest IP addr + MTU) and either fragment the datagram or send back an 1 ICMP Too Big. Basic language for the spec is: IPAE routers which are the IP recipients of IP/ICMP messages must cache ``Can't Fragment'' (``Too Big''). Router Table Size We did an extended case analysis of the current and projected sizes for 3 different router tables: The Source Information Base is the raw stuff that comes in from the routing protocol(s). The Real-Time Table is used for doing that actual data-handling of actual packets. The Policy table is whatever set of contingent rules are needed to turn the first table into the second. I have intentionally not used more typical terms for the tables, since we ran into some nomenclature confusion during the discussion. Note that the IPAE secton is divided into two, since the border routers need to maintain a set of IPAE routing tables as well as a set of IP routing tables (for the commonwealth.) SOURCE INFO BASE REAL-TIME TABLE POLICY (Variable, xmit (Variable, compute (Static) + storage overhead) + storage overhead) Now: All nets*neighbors All nets All nets IPAE: (Same as Source All nets Info Base, but (includes the IP: Attached cwlth without the IPAE/IP address nets "* neighbors" map needed during component) transition while IPAE: CWlth hierarchy, IP addresses only as needed. are still unique) (e.g., [all countries + attached metro/provider] * neighbors) 2