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

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 1 Jul 2012 17:12:32 -0500

I'm always in favor of simple solutions that don't have a lot of prerequisites. But I do get the complaint that a fixed 96-bit multicast prefix invalidates the embedded RP technique.

So for example, let's say we have an IPv4-only transit network, surrounded by IPv6 networks. And multicasts that want to be receivable by hosts on either 6 or 4 networks.

The edge routers to IPv6 networks, from this IPv4-only network, are presumably all smart enough to speak IPv6 on the outside interfaces. So we create an "all routers" multicast, inside the IPv4-only network, that periodically transmits a static table showing the mapping of IPv4 address to IPv6 multicast prefix. That way, all egress routers can reformulate the IPv6 header.

This would seem to make tunneling, dependence on PIM-SM, and multicast duplicating unnecessary in the IPv4 network, no?

This is not my use case, as we have dual stacked networks. However if faced with such a problem, I would not hesitate to cook my own solution along these lines. Did I miss some fundamental problem?

Bert

> -----Original Message-----
> From: Tina TSOU [mailto:[email-masked]]
> Sent: Friday, June 29, 2012 9:41 PM
> To: Manfredi, Albert E; Stig Venaas
> Cc: [email-masked]
> Subject: RE: [MBONED] An alternative to draft-ietf-mboned-64-multicast-
> address-format?
> 
> 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
> 
> 
> > -----Original Message-----
> > 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]
> > Subject: Re: [MBONED] An alternative to draft-ietf-mboned-64-
> multicast-
> > address-format?
> >
> > > -----Original Message-----
> >
> >
> > > 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.
> >
> > 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
> >
> > _______________________________________________
> > MBONED mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mboned

---

From: "Nagendra Kumar (naikumar)" <[email-masked]>
Date: Sun, 1 Jul 2012 08:58:01 +0000

Hi Tina,

Thanks for your thoughts. For 6-4-6 scenarios, I think it may not require to signal if or not v4 address is embedded as IPv4 cloud will be transit here. I guess Tunneling, AMT or MVPN kind of solution might be apt here.

Regarding the attribute in IPv4 only network, even if there is a requirement to transparently transfer attribute via v4 cloud, per my understanding, it still can be done by setting the F bit. So just the ingress and egress devices are required to understand the content of attribute.

Regards,
Nagendra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Saturday, June 30, 2012 7:11 AM
To: Manfredi, Albert E; Stig Venaas
Cc: [email-masked]
Subject: Re: [MBONED] An alternative to draft-ietf-mboned-64-multicast-address-format?

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

> Behalf Of Manfredi, Albert E
> Subject: Re: [MBONED] An alternative to 
> draft-ietf-mboned-64-multicast- address-format?
> 
> > 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.
> >
> 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.
> 
> 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: Mon, 02 Jul 2012 09:59:09 -0700

Hi, a few comments here on the responses below.

> Regarding the attribute in IPv4 only network, even if there is a requirement to transparently transfer attribute via v4 cloud, per my understanding, it still can be done by setting the F bit. So ju…

Just one thought here. I'm not aware of scenarios where we need to mark
an IPv4 address now (to somehow get some particular behavior for
transition), but I want to point out that the technique of using PIM
join attributes (or IGMP aux data) as specified in this draft, could
in theory be used for some kind of marking of IPv4 groups too. While
we of course never could reserve a bit in the IPv4 address. I can't
think of any uses right now though.

More below.

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

I think we're all talking about that last 32 bits being the IPv4 address
at least. Right? The only question is how a router (and maybe other
entities) can know that a particular IPv6 group address has an IPv4
address in the last 32 bits.

It can be done by a reserved well-known prefix, or a reserved flag.
Or it can be a non-defined prefix where devices need to be configured
or dynamically learn which prefixes are used. Or it can be some marking
in a PIM join or other places where the group address is used, without
putting it in the group address itself. As in this latest draft.

Stig

---

From: Tina TSOU <[email-masked]>
Date: Mon, 2 Jul 2012 18:33:33 +0000

Hi Nagendra,
Thank you. I agree with you that the most apt solution for IPv4 transit would be tunneling, AMT or MVPN. As that scenario is not to be considered, do you think complicating the addressing scheme with additional attributes is worth the effort put in implementing it? Though the solution is thoughtful and a good one, I am seeing from the implementation point of view.

Tina

> From: Nagendra Kumar (naikumar) [mailto:[email-masked]]
> Sent: Sunday, July 01, 2012 1:58 AM
> To: Tina TSOU; Manfredi, Albert E; Stig Venaas
> Cc: [email-masked]
> Thanks for your thoughts. For 6-4-6 scenarios, I think it may not require
> to signal if or not v4 address is embedded as IPv4 cloud will be transit
> here. I guess Tunneling, AMT or MVPN kind of solution might be apt here.
> 
> Regarding the attribute in IPv4 only network, even if there is a
> requirement to transparently transfer attribute via v4 cloud, per my
> understanding, it still can be done by setting the F bit. So just the
> ingress and egress devices are required to understand the content of
> attribute.
> 
> Regards,
> Nagendra
> 
> 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: Behcet Sarikaya <[email-masked]>
Date: Mon, 2 Jul 2012 15:17:15 -0500

On Sat, Jun 30, 2012 at 11:47 AM, Tom Taylor <[email-masked]> wrote:

>
> It would be good to preserve the advantages of embedded RP. You certainly
> can't have a well-known /96 and use embedded RP.

Why not?

If the translator is able to use an IPv6 Embedded-
RP prefix to represent IPv4 ASM groups on the IPv6 network, no
modifications are required
to the configuration of other PIM routers.

(From Teemu's thesis).

Behcet

---

From: Tom Taylor <[email-masked]>
Date: Mon, 02 Jul 2012 16:35:31 -0400

Your statement is correct, but has nothing to do with a well-known /96. 
That's why I was ruminating on the possible use of a reserved bit to 
indicate the presence of an embedded IPv4 address.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 02 Jul 2012 18:01:22 -0400

> to the configuration of other PIM routers.

This would not be a well-known 96-bit prefix.  The information 
describing the RP address (within that /96) would change based on which 
network is maintaining the RP.

Regards,
Brian

---

From: Stig Venaas <[email-masked]>
Date: Mon, 02 Jul 2012 18:47:43 -0700

On 02.07.2012 15:01, Brian Haberman wrote:
> This would not be a well-known 96-bit prefix. The information describing
> the RP address (within that /96) would change based on which network is
> maintaining the RP.

It could work if everyone used the same RP address ;) Sort of an
anycast RP address. It would probably not be a good idea though.

Of course we could argue whether we need to support embedded-RP.
It is very useful, especially inter-domain, but if that is not a
requirement, we may not need to support it.

Stig

---

From: "Nagendra Kumar (naikumar)" <[email-masked]>
Date: Tue, 3 Jul 2012 05:34:35 +0000

Hi Tina,

Thanks for the comments. With IPv6 source based scenarios, per my understanding, current proposals (embedded bit or flag in PIM/MLD) may not be sufficient (atleast in current state) to build the tree. But as Stig mentioned, we could use some kind of marking (or that sort) in join attribute for IPv4 groups too. 

I agree with your comment that both idea got its own pros and cons. So we would like to put it on table to discuss and understand others view on the same :)

Thanks again for your comments.

Thanks,
Nagendra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Tuesday, July 03, 2012 12:04 AM
To: Nagendra Kumar (naikumar); Manfredi, Albert E; Stig Venaas
Cc: [email-masked]
Subject: Re: [MBONED] An alternative to draft-ietf-mboned-64-multicast-address-format?

Hi Nagendra,

Tina

> Subject: RE: [MBONED] An alternative to 
> Thanks for your thoughts. For 6-4-6 scenarios, I think it may not 
> require to signal if or not v4 address is embedded as IPv4 cloud will 
> be transit here. I guess Tunneling, AMT or MVPN kind of solution might be apt here.
> 
> Behalf Of Tina TSOU
> 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-form
> at- 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 
> attributes in an
> > > 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.
> > >
> > available to an egress router? Or are we saying that it's okay to 
> > have incompatible solutions depending on each use case?
> >
> > Bert
> >

---

From: <[email-masked]>
Date: Thu, 26 Jul 2012 10:57:12 +0200

Hi Stig, all,

The main purpose of draft-ietf-mboned-64-multicast-address-format is to specify the following: 

* an address format to embed an IPv4 address into an IPv6 address
* how to extract an IPv4 address from an IPv4-embedded IPv6 multicast address
 
draft-ietf-mboned-64-multicast-address-format concludes that it is useful to identify an IPv4-embedded IPv6 multicast address compared to a native IPv6 multicast address for the reasons listed in http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02#page-11.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] 
>De la part de Stig Venaas
>Envoyé : jeudi 28 juin 2012 23:57
>À : [email-masked]
>Objet : [MBONED] An alternative to 
>draft-ietf-mboned-64-multicast-address-format?
>
>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