| United States IPv6 Summit reveals
new Internet opportunities in North America
Multicast applications are centered around timely and cost effective distribution of data, such as the distribution of financial information to analyst's desks or video streaming to a large number of receivers, and are also used for discovery of resources on the network (for example, in the multicast DNS protocol). Multicast can be used on the LAN (where it's now almost ubiquitous), inside Enterprise and campus networks (where it is common) and between networks or on the global Internet (where a lack of deployment limits uses to special situations or advanced networks such as the Internet 2 in the U.S. and similar networks abroad). Multicasting can be one to many, as in video broadcasting; many to many, as in video conferences; or even many to one (as is common in video surveillance). In each case, the basic idea is that rather than sending a separate copy of the data for each recipient, each source sends its data only once, and routers along the way to the destinations make copies as needed. All of the complexity of figuring out the path to the receivers (and, indeed, who and where the receivers are) is left to routers in the network, and can be ignored by the source. Multicasting in Internet Protocol version 6 (IPv6) is in many ways similar to Internet Protocol version 4 (IPv4). The core basics of IP Multicasting include the use of a Multicast Group Address (where data is sent to) and the use of a local group management protocol (so that host computers do not have to worry about the details of the Multicast routing protocol in use). While IPv4 Multicast group addresses are restricted to 224/8 (the range between 232.0.0.0 and 239.255.255.255), in IPv6 multicast addresses simply begin with an octet set to all ones (in other words, any IPv6 address from ff00::/8 is a multicast group address). As for protocols, the Internet Group Management Protocol (IGMP) is replaced by the very similar Multicast Listener Discovery (MLD) protocol, and the most common multicast routing protocol, Protocol Independent Multicast (or PIM), hardly changes at all. The much larger IPv6 address space available for Multicasting does mean that there is much more freedom in assigning Multicast addresses than in IPv4, and a series of Internet Engineering Task Force (IETF) Requests for Comments (RFCs) have taken advantage of this freedom. Just as a reminder, IPv6 uses a 128-bit address, and current IPv6 unicast addressing uses the first 64 bits of this to actually describe the location of a node, with the remaining 64 bits being used as an endpoint identifier, not used for routing. (Unicast IPv6 addressing is described further in an article by Steve Silverman in the January 2005, 6Sense Newsletter.) IPv6 multicast does not use the endpoint identifier approach of IPv6 unicast. The basics are set out in RFC 3513: the first octet (byte) of all multicast addresses is all ones, and the second octet is used for a series of 4 (single bit) flags, plus 4 bits for Multicast "scoping." RFC 3513 only specified one flag, to distinguish between permanently-assigned ("well-known") multicast addresses, assigned by the Internet Assigned Number Authority (IANA), and "transient" addresses. (As a general rule, well-known multicast addresses are used for internal signaling by protocols, typically from one router to others in the vicinity.) RFC 3513 also specified a set of scoping values (so that Multicasts can be automatically limited, say to the local LAN), and left 112 bits for addressing. The addressing scheme of RFC 3513 was enhanced in RFC 3306, which assigned a second flag to allow a user to use Multicast addresses based on their unicast prefix (the address block given out to each network on the Internet; every end node has an address that starts with their unicast prefix, and nodes on the same local network will generally share the same network prefix). This takes advantage of the restriction of unicast addressing to 64 bits, while 112 are available for Multicast routing -- no prefix can be longer than 64 bits, which fits within Multicast's 112 bits with room to spare. This means that RFC 3306 compliant devices can start Multicasts using group addresses drawn from "their" Multicast address prefix without any coordination with IANA or a Routing Registry, but still with no danger of colliding with other Multicasts. This powerful idea was extended in RFC 3956 (by specifying another flag) to include the address of the Rendezvous Point (RP) inside a Multicast address, a practice called embedded-RP. In Multicasting, the network needs be told something about the Multicast group in order for the packets to be routed. In practice, this has to be either the unicast address of the source (the basis of Single Source Multicast, or SSM), or the unicast address of a RP (which all routers are assumed to know). The use of a RP creates a problem in inter-domain Multicast. How does a router in company X's network know about an RP in company Y's network? RFC 3956 and embedded-RP solve this very elegantly -- the address of the RP is included directly in the Multicast group address. RFC 3306 and 3956 provide easy to implement solutions to network problems
that are simply unavailable in IPv4. There is a common misconception in
the networking world that IPv6 doesn't really provide much more
than a larger address space. The Multicast experience shows that this
is not true, and I feel certain that such IPv6 only solutions will become
common as the technology develops. |