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.
