Re: [MBONED] An alternative to draft-ietf-mboned-64-multicast-address-format?

[Stig Venaas <[e-mail]>]

On 28.06.2012 16:06, Manfredi, Albert E wrote:
>> -----Original Message-----
>> From: Stig Venaas [mailto:[e-mail]]
>
>> I don't think you can have just 96 fixed bits though. I'm not quite
>> sure
>> what you mean by predictable.
>>
>> If there is nothing in say a PIM (S,G)-join (in the group address or in
>> the PIM message) to say that G has a 32-bits IPv4 multicast address
>> embedded, then the best I can think of is to configure the devices so
>> that they know that a specific IPv6 prefix has an address embedded. But
>> I don't think it can be a fixed well-known hardcoded address.
>
> For networks that are NOT dual stack, the scheme has to work for 6 to 4 and 4 to 6.
>
> So, the way I see it working, the easiest solution is to have a single, fixed, 96-bit IPv6 multicast prefix, for multicasts that have to do this traversing back and forth.

Yes, this can work. And is also what I've been assuming in a couple
of drafts a wrote some years ago.

This can be a well-known prefix (say specified in an RFC), but I think
I might prefer implementations to rather be configured. But that means
I think, that there need to be some coordination between different
devices.

To solve this, there is draft-ietf-mboned-64-multicast-address-format.
Now I'm saying that this draft may be an alternative way of
accomplishing this.

I think we may need to further consider solutions to see what is needed.
There is a draft in WGLC in softwire though that makes use of the
address-format draft.

> 1. The ingress router to an IPv4-only network can detect that the IPv4 address is embedded.
>
> 2. The egress router from the IPv4 network to the IPv6 network can know what IPv6 prefix to add.
>
> I don't see how a flag in the IPv6 multicast address can solve both problems, UNLESS we also create a new subgroup of IPv4 multicast addresses?

For multicast things are kind of reversed. From say PIM perspective, you
can start out with someone joining an IPv6 group where the last 32 bits
form an IPv4 group address. When this IPv6 join reaches say a device on
the edge of the IPv4 network, it can based on configuration (or
hard-coded if a standardized prefix), or a flag in the group address,
or a join attribute (these are the solutions I think we have on the
table), know that it should extract those 32 bits, and join the IPv4
source. When it receives IPv4 data packets, it can based on its PIM
state know what IPv6 address to translate them to.

There are other use-cases, this is maybe the easiest one.

Stig

> Bert