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

From: Stig Venaas <[email-masked]>
Date: Thu, 28 Jun 2012 14:57:01 -0700

The draft draft-ietf-mboned-64-multicast-address-format specifies as you
know, a new flag to indicate that an IPv4 multicast address is embedded.
This is useful for translators (and maybe other devices) that can then
extract the IPv4 address and doing operations as needed on that address.

I would like to present a possible alternative, and hear your thoughts.
What if instead, when the group address is specified in a PIM join, or
an MLD report, there was a flag as part of the PIM/MLD message that
indicated that an IPv4 address is embedded?

A new draft describing this is available at
http://tools.ietf.org/html/draft-kumar-mboned-64mcast-embedded-address-00

What do you think? Might this be an alternative? Are there other
cases (apart from receiving a PIM join or an MLD report), where we
need to know that an IPv4 address is embedded in the group address?

Stig

---

From: Tina TSOU <[email-masked]>
Date: Thu, 28 Jun 2012 22:11:26 +0000

The AD said draft-ietf-mboned-64-multicast-address-format has been moved to WG 6man.

Tina

On Jun 28, 2012, at 2:58 PM, "Stig Venaas" <[email-masked]> wrote:

> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Stig Venaas <[email-masked]>
Date: Thu, 28 Jun 2012 15:23:28 -0700

> The AD said draft-ietf-mboned-64-multicast-address-format has been moved to WG 6man.

I know. But I think whether this alternative approach can work is
something we probably need to consider here in mboned. We are the
ones that are looking at translation mechanisms and need some kind
of mechanism to show that an IPv4 address is embedded.

Stig

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 28 Jun 2012 17:26:04 -0500

Wait, is there any reason to require anything more than a predictable IPv6 multicast address prefix for this?

Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Thursday, June 28, 2012 6:23 PM
To: Tina TSOU
Cc: [email-masked]
Subject: Re: [MBONED] An alternative to draft-ietf-mboned-64-multicast-address-format?

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 28 Jun 2012 15:33:04 -0700

> Wait, is there any reason to require anything more than a predictable IPv6 multicast address prefix for this?

This would be instead of a predictable prefix.

Regarding predictable prefix. As in
draft-ietf-mboned-64-multicast-address-format

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.

Stig

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 28 Jun 2012 18:06:08 -0500

> From: Stig Venaas [mailto:[email-masked]]

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

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?

Bert

---

From: Stig Venaas <[email-masked]>
Date: Thu, 28 Jun 2012 21:03:50 -0700

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

> 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

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 29 Jun 2012 14:35:09 -0500

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

This seems similar yo what I had described, except that the 96-bit prefix is configurable (presumably there will be an OOB mechanism to indicate what the prefix should be), AND it also seems to depend on PIM.

What about cases in which PIM isn't used? For example, where proxy IGMP or proxy MLD is used, to make multicasts traversing a network available to an egress router? Or are we saying that it's okay to have incompatible solutions depending on each use case?

Bert

---

From: Stig Venaas <[email-masked]>
Date: Fri, 29 Jun 2012 14:32:15 -0700

> This seems similar yo what I had described, except that the 96-bit prefix is configurable (presumably there will be an OOB mechanism to indicate what the prefix should be), AND it also seems to dep…

I guess I could try to explain why I think a fixed well-defined prefix
is a bit too limiting. It could work in some cases though. When I say
configurable, it could in theory be passed via some other protocol.

> What about cases in which PIM isn't used? For example, where proxy IGMP or proxy MLD is used, to make multicasts traversing a network available to an egress router? Or are we saying that it's okay…

For this new proposal, we're describing a flag that can be used in
IGMP/MLD messages, so not just PIM. Using a bit in the group address
also obviously works for IGMP/MLD.

Do you think we should have some discussion along these lines in the
next mboned meeting? I would be happy to try to present all the
alternatives.

Stig

---

From: Tina TSOU <[email-masked]>
Date: Sat, 30 Jun 2012 01:41:22 +0000

The fixed 96 bits and then 32 bits of the IPv4 address is a simpler and better approach according to me, as described in http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02. However, this http://tools.ietf.org/html/draft-kumar-mboned-64mcast-embedded-address-00 document has its advantages of 6-4-6-4 scenario which is missing in the alternative document. The only point I would like to stress upon is if it covers the scenario of 6-4-6, as IPv6 multicast address expressed in terms of IPv4 is something I didn't find in the document. I am only concerned about the validity of the attributes in an IPv4 only multicast network. Would tunnels be used to route the IPv6 packets with the end routers being dual stack?

Tina

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Manfredi, Albert E
> Sent: Friday, June 29, 2012 12:35 PM
> To: Stig Venaas
> Cc: [email-masked]
> This seems similar yo what I had described, except that the 96-bit prefix
> is configurable (presumably there will be an OOB mechanism to indicate
> what the prefix should be), AND it also seems to depend on PIM.
> 
> What about cases in which PIM isn't used? For example, where proxy IGMP or
> proxy MLD is used, to make multicasts traversing a network available to an
> egress router? Or are we saying that it's okay to have incompatible
> solutions depending on each use case?
> 
> Bert
>

---

From: Tom Taylor <[email-masked]>
Date: Sat, 30 Jun 2012 12:47:53 -0400

I think such a discussion would be a great idea. As usual we need use 
cases to measure the proposals against. You seem to have some in mind 
when you refer to "some cases". We also need criteria. One of them is 
the amount of administration required.

It would be good to preserve the advantages of embedded RP. You 
certainly can't have a well-known /96 and use embedded RP. RFC 3956 
seems to leave four bits open (aside from the unused flag) -- the four 
bits between scop and RIID. One could contemplate using one of those to 
indicate that an embedded IPv4 address is present as well as an embedded 
RP address. That still leaves the need for an equivalent representation 
when not using embedded RP.

>>> -----Original Message-----
...
>> What about cases in which PIM isn't used? For example, where proxy
>> IGMP or proxy MLD is used, to make multicasts traversing a network
>> available to an egress router? Or are we saying that it's okay to have
>> incompatible solutions depending on each use case?
>