IPNG Directorate Teleconference January 25, 1994 Reported by: Jim Bound This was an open IPng meeting held over the mbone. The discussion topic was IPv4 only and IPng only stacks interoperating across a network path. It was specifically stated that no mention of any IPng proposal should be discussed and would be stopped if it began. The discussion started by describing the problem space for the topic. If it is a requirement that an IPng proposal provide a technical solution to support interoperation between IPng only and IPv4 only systems, then this will effect the required strategy for a transition plan from each proposal. To support this interoperation would require at a minimum packet translation and address translation. The meeting then discussed the reasons that may exist for this interoperation and why systems may have a requirement at times to support an IPng only protocol implementation as follows: 1. Resource poor systems that cannot support two stacks (e.g. Real-Time Kernels, Light Switches, PC implementations). 2. Minimize the cost of systems to support two protocol implementations. 3. Reserve bandwidth on Hosts for performance gains per the integration of the network code base with the rest of the Host operating system code base. A discussion point brought forward was that maybe it was not an issue of supporting two protocols, but rather it needed to be determined how to reduce or minimize the cost of a dual stack on a Host. There were differing opinions on whether this was just pointing to the problem and that the 3 items above were addressing the problem rather than defining the problem. Another view expressed was that this interoperation could be added value from any proposal if their market assumptions felt it was a required feature for an IPng proposal. This basically stated that if a proposal did provide a solution for this interoperation it should not be construed to be bad by the IPng Directorate, but a resolution to solving the problems listed in the 3 items above. It was also noted by several meeting participants that they have first hand historical experience that legacy systems that do not go away for a long time, and they may also continue to support IPv4 only for some time. If suppliers did deliver IPng only systems to the market with IPv4 not supported, those systems would have to interoperate their legacy systems. The discussion then drifted to a mini technical discussion of the address translation concerns. It was general consensus that this creates a complex set of problems for network providers and network managers. That if this interoperation was required then it had to be defined clearly by any proposal. But, it was questioned without resolution in the meeting whether this should be an IPng requirement. It was proposed that an IPng architecture could provide this interoperation, but would clearly have to provide a technical explanation for two problems: 1. Where are the mappings generated for translation. 2. What will happen once IPv4 addresses are not globally unique. It was felt that CIDR aggregates as an example would reduce these mapping tables. One suggestion was that if this interoperation was needed and would take place some registered authority could provide a place where the mappings could be down loaded to sites providing this translation, that would also be coordinated with the root BIND DNS name and address space infrastructure. It was then discussed that Network Address Translation (NAT) boxes would get deployed in the market to solve the problem and would actually be a business. There was an objection to how this would happen, because of the Open Systems philosophy in the market partially developed by TCP/IP. The objection stated that the IETF needed to provide some solution to this problem so that interoperability between any NAT boxes would be maintained through IETF specifications. If this product set emerged in the market then the customers and network providers who required the operation between IPv4 only and IPng only would have some specified architecture to implement the solution, when working with providers supporting the translation of IPv4 and IPng. It was generally felt the meeting did a good job of flushing out the reason for this interoperation and those technical concerns with implementing a solution. It was not decided during the meeting through any consensus (or asked for) whether this interoperation should be an IPng requirement. The meeting provided the IPng Directorate with further data to pursue this concern as one of its functions as a member body of the IPng Area in the IETF.