Subject: [BEHAVE] DNS64 handling of multicast addresses

From: Jyrki Soini <[email-masked]>
Date: Thu, 06 Aug 2009 10:01:35 +0300

Should DNS64 draft say something specific on how to handle multicast IP 
addresses?
--
Jyrki Soini

---

From: liu dapeng <[email-masked]>
Date: Fri, 14 Aug 2009 22:08:01 +0800

Hi Jyrki:

Why should we consider multicast address in DNS64?

BR,
Dapeng Liu
2009/8/6, Jyrki Soini <[email-masked]>:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Stig Venaas <[email-masked]>
Date: Fri, 14 Aug 2009 11:07:07 -0700

> 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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 Aug 2009 14:28:28 -0400

> as for unicast, except of course that you need different prefix(es) when

Why would it be useful?  In particular, what multicast v4 services are
you suppising exist?  Last I heard, multicast is a complete dud under
IPv4, although I'd be pleased to be wrong.  I'd way prefer to make
these DNS64 tricks as simple as possible.  That might be at the
expense of more esoteric services; everything I've ever heard about
multicast and v4 suggests that it meets the criteria to be considered
exotic.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Stig Venaas <[email-masked]>
Date: Fri, 14 Aug 2009 11:48:53 -0700

> multicast and v4 suggests that it meets the criteria to be considered

IPv4 multicast is used many places, but rather than try to list that
here (although maybe I need to), I would just like to say again that I
think it would be useful for DNS64 mechanisms in general to allow for
configuration specifying how different IPv4 prefixes should be mapped to
IPv6. Allowing different IPv4 prefixes to be mapped to different IPv6
prefixes, and maybe also some prefixes like RFC1918 ones to be ignored.

Would you agree that could be useful for unicast?

With that mechanism in place, DNS64 would work well with multicast
without having to care about multicast at all. It would then be left to
the administrator whether to configure mappings that allow multicast.

Stig

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 Aug 2009 14:57:27 -0400

> Would you agree that could be useful for unicast?

That's not the problem we're trying to solve.  We're trying to solve a
limited number of IPv4/IPv6 inter-networking cases, according to the
priorities established by the Chairs.  (This limited applicability is
also why we have not so far used the DNS64 draft to specify DNS46 as
well.  Neither have we attempted to solve properly the DNS44 problem,
which has existed for many years in split-brain scenarios.)

I sometimes get dirty looks when I say this out loud, but in my
opinion DNS64 and all its friends are filthy hacks that we are
specifying only because in the past, when we said, "That's ugly and
wrong lalalala I can't hear you," to things people were going to do
anyway, it resulted in deployed technology than was even worse than
the bad things people originally found objectionable.  In other words,
this is least-bad, not actually good.  So there has to be some
compelling and existing use case to make the inclusion of special text
or completely generic approaches worth the effort.

Unless, of course, you have a proposal for text specifying the
technique completely generically.  In which case, I'm interested in
the text, please.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 14 Aug 2009 15:05:56 -0400

Andrew Sullivan a écrit :
> IPv4, although I'd be pleased to be wrong. 

multicast is used a lot within ISP networks to deliver IP streaming,
IP-TV services. but inter-AS multicast has been almost inexistant.
Therefore, Stig work is relevant for within ISP networks.

Marc.

> I'd way prefer to make

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 14 Aug 2009 12:22:56 -0700 (PDT)

I see DNS/NAT64 as being most relevant in the inter-domain context (aka across the Internet).  I don't need to NAT64 to things in my own intra-domain environment. For intra-domain, i can solve my own problem with dual-stack or load-balancers acting as proxies.

Multicast is exotic, and the cases where it is not exotic is the intra-domain context ... and i don't need NAT64 for intra-domain.

Cameron Byrne
Principal Engineer
T-Mobile USA.

--- On Fri, 8/14/09, Andrew Sullivan <[email-masked]> wrote:

> From: Andrew Sullivan <[email-masked]>
> Subject: Re: [BEHAVE] DNS64 handling of multicast addresses
> To: [email-masked]
> Date: Friday, August 14, 2009, 2:57 PM

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 15 Aug 2009 21:08:43 +0200

Hi,

some comments below...

Stig Venaas escribió:
> DNS is not much used for multicast.

based on this observation....

> But it is used to some extent, and

I think this is the best way forward at this stage.
I mean, we have a very tight schedule for DNS64 (it is supposed to be 
out to the IESG for november)
Each time we add more stuff is likely it will get more dleayed and if 
delayed the document becomes less relevant, so i would rather have this 
in a different document

I think it would make more sense to have a different document DNS64 
extensions for multicast to deal with this issue.

> synthesizing an AAAA record.

right, this should be added to the dns64 document

> And perhaps add that the same technique

mmm, i would rahter have a reference to your multicast document

> should get which IPv6 prefix, and also allow for e.g. excluding RFC1918.

that makes sense to me

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 15 Aug 2009 21:15:53 +0200

> technique completely generically.  In which case, I'm interested in

mmm, what i understood stig suggested is that:
- as a minimum, the DNS64 shoudl check some the IPv4 addresses it 
receives in the A RR and see if they fall in some special IPv4 prefixes 
(such as a multicast prefix or private address prefix or some other 
special prefix). In the address does contain one of these special 
prefixes, it should not synthesize an AAAA RR.
- In addition, it could be possible to configure different Pref64 for 
the different prefixes. So, for all the public unicast address space use 
one or more pref64, bit if the IPv4 address is a muticast address, then 
use a different pref64 and possibly doing this with different pref64 for 
different ipv4 special prefixes.

I think it makes sense to have a list of v4 prefixes for which the dns64 
does not create synthetic AAAA RR. I mean, would it make sense to 
synthesize a AAAA RR from an A RR that contains an IPv4 multicast address?

Regards, marcelo

---

From: Mark Andrews <[email-masked]>
Date: Mon, 17 Aug 2009 09:28:06 +1000

In message <[email-masked]>, marcelo bagnulo braun writes:
> Andrew Sullivan escribi:

DNS64 is a unicast translator, i.e class A, B and C address.  Class
D and E are out of scope for DNS64.  Anything else is local configuration.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Stig Venaas <[email-masked]>
Date: Mon, 17 Aug 2009 12:03:49 -0700

>> should get which IPv6 prefix, and also allow for e.g. excluding RFC1918.

I'm fine with what you wrote Marcelo. But one thing I'm trying to say
which it might seem you and others have not quite understood (at least
it looks that way to me), is that DNS64 can work for multicast without
any support for it.

As I wrote in the text above, it might be useful in DNS64 to configure
that some IPv4 ranges should get one IPv6 prefix, and some other ranges
another. And maybe that some IPv4 ranges should be ignored.

If you think that is useful, please consider adding that to the draft.
I think that is useful for _unicast_.

DNS64 implementations with that flexibility could be configured to
handle multicast. I think that would be cool, but you don't need to
mention multicast in the draft, it's just a configuration thing.

Stig

---

From: Jyrki Soini <[email-masked]>
Date: Tue, 18 Aug 2009 11:30:24 +0300

> synthesize a AAAA RR from an A RR that contains an IPv4 multicast address?

As Stig Venaas pointed out, if the DNS64 is able to handle multiple
IPv6 prefixes for synthesizing the AAAA record based on IPv4 address
ranges on returned A records the multicast would not need any additional
mechanism in DNS64.

I think that best way forward would be to specify synthesizing IPv6 
multicast addresses in draft-venaas-behave-mcast64 (there might be some 
considerations on scopes and ASM/SSM).

I propose the following text (marked with +) will be inserted to
draft-ietf-behave-dns64

5.  DNS64 Normative Specification

    A DNS64 is a logical function that synthesizes AAAA records from A
    records.  The DNS64 function may be implemented in a stub resolver,
    in a recursive resolver, or in an authoritative name server.

+ The implementation SHOULD support mapping of IPv4 address ranges to
+ separate IPv6 prefixes for AAAA record synthesis. This allows handling
+ of special use IPv4 addresses [draft-iana-rfc3330bis-09]. Multicast
+ address handling is further specified in [draft-venaas-behave-mcast46].

and modifying existing paragraph later in 5.1 with:

    If the query results in no error but an empty answer section in the
    response, the DNS64 resolver attempts to retrieve A records for the
    name in question.  If this new A RR query results in an empty result
    or in an error, this result is returned to the client.  If the query
    results in one or more A RRs,
+ the DNS64 SHOULD check each A RR against IPv4 address ranges and
+ select the corresponding IPv6 prefix for synthesizing AAAA RR.
- the DNS64 synthesizes AAAA RRs based on the A RRs.
    The DNS64 resolver then returns the synthesized AAAA
    records in the answer section to the client, removing the A records
    that form the basis of the synthesis.

--
Jyrki Soini

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 17 Aug 2009 18:12:17 +0200

> D and E are out of scope for DNS64.  Anything else is local configuration.
fair enough, so this requires for the first option i described above 
i.e. the dns64 needs to check that the address int he A RR is part of 
the class A,B and C space. If it is not, it will not synthesize the AAAA 
RR, correct?

Is there any other special cases we need to handle?
What about private addresses, should we create synthetic AAAA RR for A 
RR with private addresses inside?

Regards, marcelo

---

From: Stig Venaas <[email-masked]>
Date: Tue, 18 Aug 2009 07:35:01 -0700

Jyrki Soini wrote:
[...]
> considerations on scopes and ASM/SSM).

Yes, I certainly think a more detailed discussion need to go somewhere
else, e.g. that draft.

> + address handling is further specified in [draft-venaas-behave-mcast46].

Looks good.
>    that form the basis of the synthesis.

And this too. These changes are exactly what I was asking for :)

Stig

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 18 Aug 2009 12:50:41 -0400

Mark,

> D and E are out of scope for DNS64.  Anything else is local configuration.

What about the suggested text from Jyrki Soini, downthread?  It seems
to be consistent with what you are suggesting while allowing for the
requested behaviour.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Aug 2009 13:10:33 +1000

> to be consistent with what you are suggesting while allowing for the

Something like that would be fine.

I would still exclude Class E addresses.

I would add text to ensure that Class D are mapped into FF00::/8
(or whatever the correct IPv6 multicast prefix is).

I would describe these as a unicast prefix and multicast prefix and
say that the unicast prefix only applies to Class A, B and C
addresses.  Similarly the multicast prefix only applies to the Class
D addresses.  That way you you can use 0.0.0.0/0 when checking which
addresses matches rather than having to use 0.0.0.0/1 + 128.0.0.0/2
+ 192.0.0.0/3 as the default matching acl in configs for the unicast
addresses.

Mark

---

From: Stig Venaas <[email-masked]>
Date: Tue, 18 Aug 2009 21:23:17 -0700

> + 192.0.0.0/3 as the default matching acl in configs for the unicast

With longest prefix match one could maybe say

0.0.0.0/0 -> some prefix
224.0.0.0/4 -> ignore

Anyway, I suggest implementations can figure this out. We can just say
that by default multicast addresses should be ignored.

I think ignore is useful for 127.0.0.0/8, and the RFC1918 ranges etc. as
well.

Stig

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Aug 2009 14:34:04 +1000

> I think ignore is useful for 127.0.0.0/8, and the RFC1918 ranges etc. as

127.0.0.0/8 maybe

RFC1918 no.  I can well see this being used internally to connect
to local legacy devices instead of running dual stack internally.
If you get RFC1918 addresses from the DNS then translating them is
the correct thing to do.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 18 Aug 2009 21:35:07 -0700

> If you get RFC1918 addresses from the DNS then translating them is

Agree, but I think it needs to be configurable,

Stig

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 Aug 2009 11:20:39 +0200

> D and E are out of scope for DNS64.  Anything else is local  

Treating class E as a special case landed us in the situation where  
268 million perfectly good IPv4 addresses are unusable in practice.

So don't treat class E as a special case.

Also don't treat RFC 1918 as a special case, just in case the NAT64  
operator hosts some services on these addresses or something.

Nets 0/8 and 127/8 and 255.255.255.255/32 could be filtered as well as  
class D and maybe 169.254/16 but I'm not sure the effort of filtering  
is offset by any practical benefits.

---

From: Xing Li <[email-masked]>
Date: Fri, 21 Aug 2009 20:31:30 +0800

I think the special handling of the multicast addresses should also be 
in the xlate and/or address-format documents. xing

Stig Venaas 写道:
>>>>>> D and E are out of scope for DNS64. Anything else is local 
>>>>>> configuration

---

From: Dave Thaler <[email-masked]>
Date: Fri, 21 Aug 2009 22:04:31 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Xing Li
> Sent: Friday, August 21, 2009 5:32 AM
> To: Stig Venaas
> Cc: Andrew Sullivan; [email-masked]; Mark Andrews

I don't see why the DNS64 shouldn't be capable of doing multicast
address translation too, if such is used.  If, for example, a DNS64
is configured with a set of IPv4 prefixes and the corresponding IPv6
prefix for each, it shouldn't have to check whether the address is
unicast or multicast.  Of course either all prefixes have to have the
same suffix algorithm (zero-pad and embed, or embed and zero-pad, or
whatever else) or else you have to configure the algorithm per prefix
too.

-Dave

---

From: Stig Venaas <[email-masked]>
Date: Fri, 21 Aug 2009 15:14:37 -0700

> whatever else) or else you have to configure the algorithm per prefix

This is what I've been arguing all along in this thread. There is no
need for specific multicast capability as long as you can configure
different IPv6 prefixes to be used with different IPv4 prefixes. I
think this mechanism is useful in any case. Including a way of ignoring
certain prefixes (not synthesize AAAA).

As Jyrki wrote:

|As Stig Venaas pointed out, if the DNS64 is able to handle multiple
|IPv6 prefixes for synthesizing the AAAA record based on IPv4 address
|ranges on returned A records the multicast would not need any
|additional mechanism in DNS64.

I think Jyrki formulates my thoughts better than I can,

Stig

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Aug 2009 15:25:49 +0200

> whatever else) or else you have to configure the algorithm per prefix

I haven't followed the multicast discussion in detail, but the problem  
here is that in IPv6, there is scope information encoded in multicast  
addresses. This information isn't present in IPv4 multicast  
addressing, or at least not to the same degree. This means that it's  
necessary to add this information during the translation, and AFAIK  
this information can't be defaulted or algorithmically derived, so  
this requires additional configuration.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 27 Aug 2009 09:28:28 -0400

Iljitsch van Beijnum a écrit :
> addresses. This information isn't present in IPv4 multicast addressing,
> or at least not to the same degree. This means that it's necessary to
> add this information during the translation, and AFAIK this information
> can't be defaulted or algorithmically derived, so this requires
> additional configuration.

yes, but: one can restrict to a subset: i.e. only translate global scope
groups, which is most likely what people would need. This could be a
config switch within the translator.

Marc.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 27 Aug 2009 07:54:19 -0700

> config switch within the translator.

This is partly why I think this should be configurable. Someone managing
DNS64 and the translator can decide on what is appropriate. But yes,
it's not that hard to come up with a sensible default I think. E.g. only
global scope. Maybe map 239/8 to scope 5...

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 27 Aug 2009 11:04:44 -0400

> global scope. Maybe map 239/8 to scope 5...

for configuration purposes, a nat64 is a forwarding device such as a
router. by default, routers do not forward multicast trafic, but can if
configured to do so. Therefore, I think the nat64/dns64 should not do
any translation and forwarding of multicast traffic by default, unless
it is explicitly configured to do so.

Marc.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 27 Aug 2009 10:07:50 -0700

> it is explicitly configured to do so.

Agreed. So my points regarding DNS64 are basically:

Recommend that one can configure different IPv6 prefix mappings for
different IPv4 prefixes (and also that certain IPv4 prefixes can be
ignored).

The above would be sufficient for DNS64 to work with multicast, even
with various scopes. What exactly those mappings could be should not be
in this document.

The recommended default should be ignoring multicast addresses.

Stig

---

From: Dave Thaler <[email-masked]>
Date: Thu, 27 Aug 2009 17:14:46 +0000

> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Thursday, August 27, 2009 6:26 AM
> To: Dave Thaler
> Cc: Xing Li; Stig Venaas; Andrew Sullivan; [email-masked]; Mark
> Andrews

I would expect this to be trivially configurable simply by configuring
a set of IPv6 prefixes and corresponding IPv4 prefixes.  I.e. no
different from what you'd support for unicast, and I see no reason
to distinguish unicast from multicast for this purpose.

-Dave

---

From: Xing Li <[email-masked]>
Date: Mon, 31 Aug 2009 15:52:33 +0800

Dave Thaler 写道:
>>>>>>>> DNS64 is a unicast translator, i.e class A, B and C address.
>>>>>>>>                 
>> Class
>>     

I mean we should discuss the multicast in
(1) address-format document, since multicast addresses should be mapped 
differently compared with the unicast addresses.
(2) xlate document, since the multicast packets should be translated 
differently compared with the unicast packets.

yes, dns64 (and dns46) must defined the methods for the multicast 
name/address processing.

regards,

xing

---

From: Xing Li <[email-masked]>
Date: Mon, 31 Aug 2009 15:55:58 +0800

Stig Venaas 写道:
>>>>> addressing,

agree. xing

---

From: Dave Thaler <[email-masked]>
Date: Mon, 31 Aug 2009 17:22:52 +0000

> differently compared with the unicast packets.

I currently don't believe either of the statements starting with "since..."

Can you elaborate on why you believe them?

-Dave

---

From: Xing Li <[email-masked]>
Date: Tue, 01 Sep 2009 09:56:07 +0800

> Can you elaborate on why you believe them?
An example of stateless translator:

         ------                        -----   
       /  The   \       -----        /  An   \       
A --- |  IPv4    |-----|Xlate|------|  IPv6   | --- B
       \Internet/       -----        \Network/  
         ------                        -----   

IPv4 host A: 166.111.8.10
IPv6 host B: pref:202.112.5.6

Packets sent from IPv4 host A to IPv6 host B

Unicate:
    Before the xlate
        Src=166.111.8.10
        Dst=202.112.5.6
    After the xlate
        Src=pref:166.111.8.10
        Dst=pref:202.112.5.6

Multicast:
    Before the xlate
        Src=166.111.8.10
        Dst=233.1.2.3
    After the xlate
        Src=pref:166.111.8.10
        Dst=ff3e::1.2.3

So, for the xlate (when muticast translation is enabled)
    If the Dst address (x.x.x.x) is in the unicast address range
        Convert to pref:x.x.x.x
    If the Dst address (x.x.x.x) is in the multicast address range
        Convert to 3ffe::x.x.x

regards,

xing