I'd like to respond to one of your points. Your overall thrust
(preservation of the existing architure) is reasonable, but it is really
useful operationally for nodes to be able to recognize IPv6 multicast
addresses that contain embedded IPv4 multicast addresses. If the path
taken by the signalling and, in the reverse direction, the multicast
data crosses multiple points of transition between IPv4 and IPv6 or the
reverse, the translation at each such transition point can be done
independently, with no need to coordinate between the different
translating nodes. That holds even across domain boundaries. If a
mapping table is used instead, the same table has to be provisioned at
each translating node.
On 05/05/2012 10:12 PM, Bob Hinden wrote:
...
Or better yet, just keep a mapping table in the translator that maps
the IPv4 multicast group to an IPv6 multicast group ID? That
wouldn't require any changes in the IPv6 multicast address. If the
purpose of these boxes is to do translation, then this should be
possible, like is done with other forms of Network Address
Translation (NAT). This would also mean that you wouldn't need
anything close to 2^^32 multicast groups as I suspect the number that
will be used in practice will be much smaller.
My overall conclusion is that I don't see the need for any changes to
the IPv6 addressing architecture to support this application.
Bob
...
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
