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

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:Tina.Tsou.Zouting@huawei.com]
> Sent: Friday, June 29, 2012 9:41 PM
> To: Manfredi, Albert E; Stig Venaas
> Cc: mboned@ietf.org
> 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: mboned-bounces@ietf.org [mailto:mboned-bounces@ietf.org] On
> Behalf
> > Of Manfredi, Albert E
> > Sent: Friday, June 29, 2012 12:35 PM
> > To: Stig Venaas
> > Cc: mboned@ietf.org
> > 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
> > MBONED@ietf.org
> > https://www.ietf.org/mailman/listinfo/mboned