Re: [BEHAVE] DNS64 handling of multicast addresses

[Stig Venaas <[e-mail]>]

liu dapeng wrote:
> Hi Jyrki:
> 
> Why should we consider multicast address in DNS64?

It would be very useful to have the exact same mechanism for multicast
as for unicast, except of course that you need different prefix(es) when
you synthesize AAAAs.

Let me try to describe how it might work in the scenarios in DNS64. The
scenarios in the DNS64 draft is:

    DNS64 is used with an IPv6/IPv4 translator to enable client-server
    communication between an IPv6-only client and an IPv4-only server,
    without requiring any changes to either the IPv6 or the IPv4 node,
    for the class of applications that work through NATs.  This document
    specifies DNS64, and provides suggestions on how it should be
    deployed in conjunction with IPv6/IPv4 translators.

If you add multicast to this scenario, it would become how IPv6-only
multicast applications (clients) can receive from IPv4-only multicast
sources (streaming servers etc).

In practice it would work something like this:

The IPv6 application may receive an SDP file telling it which multicast
group to join, but by domain name rather than a literal address. The
application does a DNS lookup, this goes through DNS64. DNS64 finds just
an A record with an IPv4 multicast address. It then synthesizes an AAAA
record with an IPv6 multicast address. Application receives this and
joins the IPv6 multicast group.

The join reaches the translator which knows the mapping, joins the IPv4
group... IPv4 multicast packets coming back are translated into IPv6.

There is some complexity as to which exact prefixes to use. Anyway,
which prefix to apply to which multicast address ranges must be
configured the same on DNS64 and the translator, just like the unicast
prefix must be configured on both. It might be sufficient to distinguish
SSM from other multicast.

The scenario here (but not DNS) is described in 
draft-venaas-behave-mcast46-01 and section 5.1 talks about how IPv4
multicast addresses might be embedded into IPv6 multicast addresses
using multiple prefixes.

Much of this is also discussed in
draft-venaas-behave-v4v6mc-framework-00 which I presented in Stockholm.

Note that that document doesn't say much about DNS. It mostly says that
DNS is not much used for multicast. But it is used to some extent, and
to aid transition it may be a good idea to use it to a much larger
extent. It is easier to use a DNS ALG than to use other ALGs for
rewriting literal addresses on a whole bunch of other protocols.

I plan to add more on DNS to that document.

I think it might be a good idea to add multicast to DNS64. Alternatively
someone might at some point have to write a separate document.

I think the addition to DNS64 could be just 1-2 paragraphs, and it need
not go into much detail. I would be happy to provide further suggestions
or text.

If there is no multicast in DNS64, then it should specifically point out
that it must check that an address is an IPv4 unicast address before
synthesizing an AAAA record. And perhaps add that the same technique
could be used for multicast, but that it would require a multicast
prefix.

I think we might just as well write a slightly longer text that says
how to handle multicast.

BTW, I wonder whether there are other IPv4 addresses that DNS64 should
check against. I think it would be useful to configure which IPv4 ranges
should get which IPv6 prefix, and also allow for e.g. excluding RFC1918.

If you have that flexibility by configuration, DNS64 could be configured
to properly handle multicast, without any specific support for multicast.

Stig

> 
> BR,
> Dapeng Liu
> 2009/8/6, Jyrki Soini <[e-mail]>:
>> Should DNS64 draft say something specific on how to handle multicast IP
>> addresses?
>> --
>> Jyrki Soini
>>
>>
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
>>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave