据我了解，IANA分配的公有IPv6地址的前缀是2000 :: / 3。 这些IP地址将通过Internet路由。
另一端的IPv6组播地址前缀为FF00 :: / 8。
所以我的理解是，ipv6多播地址将不能通过互联网路由。 我是对的？ 如果是这样，有没有办法通过互联网在IPv6中进行一对多的IP路由？
谢谢！
那么我能通过互联网访问一个多播组吗？还是只能通过ipv4这样的私有networking来支持？
我必须纠正你在这里所做的一个假设。
如果你和你的目的地之间的所有路由器都支持它，那么Multicast肯定能够在IPv4互联网上运行。 它在很多地方都被阻塞或者没有configuration。 我怀疑这是因为组播不是很好理解，许多人认为他们不需要它。 所以他们根本不允许通过他们的防火墙/路由器。
IPv6当然能够像全球有组播工作的IPv4一样。 只有时间会告诉我们人们是否真的允许通过他们的networking进行多播
IPv6 public-unicast-地址的前缀为2000 :: / 3（到目前为止）。 组播的分配包括适应链路本地，各种本地范围和全局寻址（按照RFC3307）。 这与IPv4多播的基本思想是一样的，其中224/4空间的块被留出用于GLOP地址等。
查看RFC3306以及我认为它可能更直接地回答你的问题。
该规范定义了IP版本6协议的多播寻址体系结构的扩展。 本文档中介绍的扩展允许基于单播前缀的多播地址分配。 通过将单播地址同时分配给单播前缀，networking运营商将能够识别他们的多播地址，而不需要运行域间分配协议。
所以这个想法是，如果你有一个全局路由/ 64，它可以被包含在整个组ID中给你一些可以在全局路由的东西。 换句话说，如果你已经有一个v6的前缀和一个适当的载体，那么你已经设置。
这些标准允许全球组播路由，但是AFAIK目前大多数ISP仅限于使用它们的组播（IPTV等）
我自己的猜测是，很多ISP恰好是部署IPv6的有线电视提供商将在其边界上阻止它。
我认为这可能是愤世嫉俗的，但他们有保留其内容竞争对手高成本的既得利益。 v6多播将允许HBO或任何其他stream式video提供商通过多播信道将一个v6stream传输到IPv6世界，并显着降低成本。
假设你误解了多播是什么，我看到了多个答案。 你没有犯错，你的问题是清楚的。 我问自己这个问题：
我可以在IPv6 Internet上进行组播吗？
传统上，比如在IPv4中，我需要请求一个永久的全局多播地址（或子网）并将它们分配给我的networking。 IPv6仍然是可能的。 然而，IPv6本质上是组播的快乐，所以包含一些机制让我可以在不请求唯一地址的情况下进行组播。
当两个物理上分离的networking（六个人）在同一个networking游戏中有三个人时，这些优点变得明显。 选项是将数据包单播给每个播放器（每更新一次发送五个数据包）或多播（每更新一个或两个数据包）：第一个数据包将被发送到本地播放器的链路本地多播地址局域网，而另一个数据包将被发送到全局多播地址，路由器将理解的是针对其他局域网上的播放器。 甚至可能是数据包发送一次到全局多播地址，路由器（或本地客户端）知道如何处理。 后者当然会更有效率。
鉴于多播是多么有用，如果他们不得不为每个想要玩networking游戏的人分配多播前缀，或者发送video会议，或者向朋友广播现场表演等等，那么这将会刺激IANA。 。
IANA的申请表明确表示您可能不需要永久性的IPv6多播地址，这很好。
基于单播前缀的IPv6组播地址
这当然已经解决了。 标题“基于单播前缀的IPv6多播地址”应该说明一切：如果您拥有全球唯一的IPv6 IP地址，则您（您的计算机/设备）可以为您的（/）自己分配一个全球唯一的多播地址，根据您的单播分配。 要求是每个点（服务器，路由器，客户端）的软件都知道它在做什么。 旧的路由器和懒惰的ISP可能是未来几年的倒台。
find一个似乎是一个非常简单的问题的答案是非常困难的，最接近我可以find一个明确的答案在RFC3306 ：
以下是基于单播前缀的多播地址结构的一些例子。
- Global prefixes - A network with a unicast prefix of 3FFE:FFFF:1::/48 would also have a unicast prefix-based multicast prefix of FF3x:0030:3FFE:FFFF:0001::/96 (where 'x' is any valid scope). - SSM - All IPv6 SSM multicast addresses will have the format FF3x::/96.
关于IPv6多播的大多数文章（和答案）都集中在具有预定义地址的本地多播上，并不是很有帮助。 最重要的是客户端可以根据其单播地址为自己分配一个唯一的多播地址，当然范围仍然适用：
基于单播前缀的组播地址的范围不得超出embedded在组播地址中的单播前缀的范围。
由于IPv6连接性非常罕见，因此testingInternet的IPv6多播能力和可靠性对于大多数最终用户来说是不可能的，因此没有大量关于它的文章。 事实上，大多数最终用户不知道为什么他们会在家里使用IPv6多播，但应用程序已经准备就绪，正在等待。
本页面讨论了RFC引起的一些混淆， RFC3956提到了某些多播域在互相交谈时有困难。 在这一点上，它可能很难实现，但我没有看到为什么游戏服务器（从我上面的例子）不能为自己分配一个多播IPv6地址，并通知客户这个地址，而且不必乞求静态组播IPv6分配。
这是我想在未来跟进自己的事情。
步骤1：ISP需要启用IPv6。 仍然。
另请参阅： RFC6308：Internet多播寻址体系结构概述
在我看来，你混淆了两件事：多播路由和IPv6地址分配。
组播路由依赖于组播源之间的path上的所有路由器，并将组播数据包转发到要接收某个组播组的目标。 在具有完整多播networking的不受控制的networking中，任何源系统都可以在没有任何控制的情况下发送到任何多播组，并且join该组的所有系统都将接收数据。 这与任何分配无关，只是启用了多播路由。
来自2000 :: / 3的IPv6地址分配决定谁可以使用哪个单播地址。
那么谁可以使用哪个IPv6多播组就是我所知道的只有在rfc3307中定义的。
多播源对于哪些目的地看到它们的数据包没有太多的控制，很可能通过多播传输的数据达到不能通过单播传递的destion。