Re: draft-ietf-mboned-64-multicast-address-format

[Tom Taylor <[e-mail]>]

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
>
>
...