Subject: Re: [BEHAVE] Multicast translation draft

From: Stig Venaas <[email-masked]>
Date: Mon, 09 Feb 2009 13:26:25 +0100

Dan Wing wrote:
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Stig Venaas
>> Sent: Tuesday, January 20, 2009 2:12 AM
>> To: [email-masked]
>> Subject: [BEHAVE] Multicast translation draft
>>
>> A while ago I submitted the draft draft-venaas-behave-mcast46-00
>> describing an IPv4 - IPv6 multicast translator solution.
>>
>> I would appreciate any feedback on the draft,
> 
> This draft feels quite complete.  

Good to hear. I wouldn't mind improving the draft with whatever
is lacking though.

> I wrote draft-wing-behave-learn-prefix-00.txt which was 
> primarily aimed at the following problem:  I imagine it could 
> be common for the multicast application running on the IPv6-only
> host to only learn an IPv4 multicast address (via an
> electronic program guide, SDP, or whatever other means it
> might learn of multicast addresses).  But the draft requires
> the IPv6-only host join the IPv6 multicast group which requires
> the IPv6-only host somehow know the IPv6 prefix associated
> with that IPv4 address and the SSM/ASM mapping between IPv6
> and IPv4.  If I'm on track with my imagination then a discussion
> of this might be helpful.  

This is an interesting problem. It should perhaps be noted in my
draft, but I think it's good to do this in a separate document.

> 
> BEHAVE working group:  is there interest in this draft?

I think it's good. It seems to address the problem for unicast,
which I think is useful. If I understand you correctly, you are
saying we need this also for multicast, and I agree with that.

One issue with multicast, is that we may need two prefixes (one for ASM
and another for SSM) in addition to the unicast one. I can see some
possible ways the multicast prefixes could be derived from the unicast
one though.

I can think of a number of questions related to this. I'll try to list
the questions and some of my thoughts below.

First of all, one could consider not telling hosts and applications
about any prefix, and where they don't know translation is taking
place. This could kind of work as long as users or applications
somehow are told to use the appropriate IPv6 address, e.g. by rewriting
SDP. There are several issues with this, I don't want to go into detail
here and now.

Another way is to have a well-known prefix that can be hard coded in
applications or stacks whatever. But I see benefits in not having a
single fixed prefix, which I won't try to list here.

The last option then, is to have a prefix (or one for ASM and one for
SSM) that can be site dependent, which I think leaves us with a way for
applications or hosts to learn the prefix. I think we need this, and
hence I am interested in your draft.

I have some thoughts regarding how the prefix should be learned.

One choice is that applications learn the prefix. They can then know
that translation is taking place, and they can know which IPv6 groups
to join, corresponding to the IPv4 groups they have learned from SDP
or other sources. This seems like a good idea, the only issue I see is
that applications need to be modified.

Another possibility, could be to hide it from applications and do some
magic in the host stack. You could imagine that the host stack learns
the prefix. Then when an application joins an IPv4 group (signals the
stack), the stack could choose to treat it as an IPv6 join and send
the corresponding MLD report. When the stacks receive translated IPv6
multicast, it could rewrite the packets to IPv4 (from the translated
IPv6 datagram it knows the original IPv4 source and destination
addresses and ports, and of course payload), and deliver it as IPv4
to the application. I'm sure there are lots of issues with this, the
main advantage is hiding it from the application.

Finally, about DNS vs DHCP. They both could work, but a problem with
DHCP, is that you cannot really do DHCP requests directly from the
application, and if the host runs a stand-alone DHCP client, there is no
standardized way for how to provide this info to the application. Hence,
this would need to be specified as well. DNS is of course simple for the
application.

If the prefix only needs to be known to the stack, then DHCP becomes
easier (about as easy as DNS).

I tried not to go into details here. Perhaps it's worth writing them
down though.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Mon, 09 Feb 2009 16:06:37 +0100

Hi

[email-masked] wrote:
> Hi Stig,
> 
> Sorry, I have not read it yet, but is it different idea of mine?
> 
> http://www.ietf.org/internet-drafts/draft-miyata-v6ops-snatpt-02.txt

There are some similarities, but my draft goes more into the details.
One thing you suggest that I don't, is to allow specific mappings
other than just inclusion of IPv4 groups into IPv6 space. It might
be good to discuss whether that is needed or not. Maybe it is.

I think the main new contribution with my draft, is how a translator
should interact with PIM. This is important if you for instance have
a routed network behind the translator and cannot just rely on IGMP
proxying. It also allows for knowing whether there are listeners
(both IPv4 and IPv6) and only doing translation and forwarding when
needed.

Sorry for the late answer,

Stig

> See,
> 
> 11.8 Multicast Translation
> 
> Regards,
> 
> ------------------------------------
> Hiroshi Miyata,
> Ubiquitous Field Computing Research Center,
> Corporate R&D Headquaters,
> Yokogawa Electric Corp.