skip to primary navigationskip to content
 

Multicast

Most traffic crossing the internet is unicast: flowing from a single source to a single destination.  If there are multiple hosts wishing to receive the same data — for example, several people watching the same live television channel — it must be sent multiple times by the source, resulting in traffic duplication.  Multicast allows a single feed of data to be sent by the sender to multiple receivers, only duplicating data when it needs to take a diverging path for the different receivers, resulting in significantly less bandwidth being used across downlinks, even when hundreds of hosts are involved.

The Cambridge University Data Network (CUDN) backbone supports multicast internally and to and from the global internet.  Support in individual institutions connected to the CUDN is determined by the institutional network administrator — if users within an institution have any questions they should consult their local network administrator, in the first instance.

This page describes how multicast is implemented on the CUDN and is intended for institutional network administrators or advanced users.

Both IPv4 and IPv6 multicast are supported — where there are significant differences between the two protocols, these are described separately.

Note: this page describes a reconfiguration of multicast on the CUDN during 2013.  The situation until this reconfiguration takes place is different, in particular treating the whole of 239.0.0.0/8 as CUDN-wide private group addresses.  A summary of the transition progress and changes is given below.

Contents

Support on institutional connections

The process of enabling multicast routing depends significantly on the routing configuration for the institution:

  • For a directly-routed edge connection (where the CUDN router is the immediate gateway) usually little more is needed than a request to Network Support to either enable IPv4 multicast, or to add IPv6 routing to a connection.
  • For institutions with their own router, the process is considerably more complex.

Multicast on edge subnets

On edge connections (with end-user hosts attached) that are routed directly by the CUDN routers, IPv4 multicast routing to the CUDN and beyond can be enabled just by making a request to Network Support.  Once enabled, multicast to and from the CUDN and global internet will become available without further work by the institution.

IPv6 multicast routing will automatically be enabled, if a VLAN has IPv6 unicast routing on it.  It is therefore possible for an institution to have IPv4 unicast as well as IPv6 unicast and multicast enabled, but not IPv4 multicast.  IPv6 multicast routing can be selectively disabled on a VLAN-basis but this would not be the default case — there should be a good reason for doing so.

Note that multicast is intrinsic to the operation of IPv6 and will always be present on networks where IPv6 is in use, regardless of whether it is routed or not.  Even in the case of IPv4, the First Hop Redundancy Protocol (FHRP) used on the CUDN will cause the routers to regularly emit multicast traffic, even on a non multicast-enabled IPv4 network.

It is the responsibility of institutional network administrators to ensure that their network is prepared for multicast services.  In particular, the appropriate IPv4 Internet Group Multicast Protocol (IGMP) and IPv6 Multicast Listener Discovery (MLD) Snooping features on their network switches should be enabled to avoid traffic being flooded to where it is not required.

For institutions with proxy ARP routers, it is their responsibility to ensure that the appropriate traffic is forwarded through the routers (including IGMP and MLD Membership Reports for receivers) to the CUDN routers.

Multicast on routed connections

Multicast routing via an institutional router is only supported on dynamic routed link connections.  This means the institution must be running an BGP peering with the CUDN to exchange routing information.

The protocols and configuration of multicast over a dynamic routed connection differs slightly between IPv4 and IPv6 and so they are described separately, below.

Note: static routed link connections are NOT supported — the disparity between the real addresses of the CUDN routers and the statically-configured virtual first hop address do not match and fail the Reverse Path Forwarding (RPF) checks performed by a multicast router.  An institution with such a connection will need to transition to a dynamic routed link (with BGP) to support multicast.  Differences between IPv4 and IPv6 multicast may mean that this is not the case with IPv6, but this is not a supported configuration.

IPv4 multicast over a routed connection

CUDN BGP and MSDP

IPv4 multicast via routed institutional networks uses a number of protocols:

Each of these protocols is described below, along with how they are configured on the CUDN.

Multicast traffic routing using PIM-SM

Protocol Independent Multicast - Sparse Mode (PIM-SM) is the most common multicast routing protocol in use and is used to control the flow of multicast traffic around the local PIM domain by building distribution trees.  A PIM domain is typically congruent with a BGP Autonomous System (AS).  It is also used on the links to adjacent domains to join or leave groups from connected networks.

Institutions must configure PIM-SM internally to all locations where multicast is required, as well as on their backbone and the uplinks to the CUDN routers.  PIM Sparse-Dense Mode (PIM-SDM) should typically NOT be used and certainly not on the uplinks to the CUDN: the CUDN does not support Dense Mode operation and PIM-SDM would result in traffic flooding incorrectly.

Institutions must also configure a local PIM Rendezvous Point (RP).  If they have multiple routers, an appropriate method for other routers to locate the RP must be configured, e.g. static address or the PIM BootStrap Router (BSR) protocol.

On the links to the CUDN, the appropriate PIM BSR and RP advertisement boundary filtering should be configured.

Source Specific Multicast (SSM) should also be enabled, which will only allow source-specific joins to group addresses in the SSM range.

Reverse Path Forwarding routes via MBGP

The multiprotocol extensions to BGP (MBGP) are used to exchange Reverse Path Forwarding (RPF) routes with peers.  RPF routes are used to identify the route by which multicast traffic from a particular source address will arrive.  Multicast traffic from a source which does not arrive via the active RPF route will be discarded by a multicast router.  In most cases, the RPF routes used for multicast will be identical to those used for unicast: the only reason for them to differ is if parts of the network do not support multicast, or if certain links have multicast performance limits.

IPv4 multicast RPF routes will automatically be enabled when a CUDN BGP peering is set up.  Institutions must ensure that IPv4 multicast is enabled on their BGP peering and that they advertise the appropriate RPF prefixes over their peering: if not configured, other routes will be used for the RPF check which will almost certainly result in multicast traffic from an institution being dropped.

Source discovery using MSDP

PIM-SM only operates within a single domain; the Multicast Source Discovery Protocol (MSDP) is used to interconnect the RPs in adjacent PIM domains and enable inter-domain multicast.  It exchanges Source Active (SA) information about the addresses of active senders of multicast traffic, the group addresses they are sending to and the address of their "home" RP.  When traffic from this source is required, the RP router in the member's domain will send a join towards the RP in the source network, via all the intermediate networks.

If an institution requests multicast services on a dynamic routed link connection set up with BGP, an MSDP peering will be set up on the CUDN router between the same IP addresses used for the BGP peering (i.e. the CUDN and institution ends of the router links): institutions must configure MSDP to peer with the CUDN router using these addresses to receive SA messages.

If an institution has multiple routers peering with the CUDN, or an RP router which is inside their network (i.e. not one of the ones peering directly with the CUDN), then they must run MSDP internally, as appropriate.

SAs will be filtered over the institutional peering with the CUDN to remove any institution private groups from being advertised or accepted.  However, institutions should not rely on this and should also apply the appropriate inbound and outbound SA filtering on the peering at their end.  Also note that the CUDN filters CUDN-wide private groups from the peering between itself and Janet (and, thus, on to an institution), so a full internet SA feed will not be received by institutions: at the time of writing, this is typically around 4,000 entries.

MSDP is not used for Source Specific Multicast (SSM) groups and SAs will not be accepted or advertised from groups in the SSM range.

Edge connection routing using PIM-SM and IGMP

On edge subnets (with end-user hosts), PIM-SM should be enabled on the router(s) to activate multicast routing.  If PIM BSR/RP (or any other RP selection protocol, such as Cisco AutoRP) protection is available, this should be used to avoid problems with rogue announcements disrupting multicast routing.

In addition, the Internet Group Multicast Protocol (IGMP) should be enabled, preferably using version 3 to support Source Specific Multicast (SSM).  IGMP is often enabled by default but sometimes requires explicit configuration to use version 3; if hosts that only support version 2 are present, an IGMPv3 router will automatically downgrade.

IGMP is also snooped by edge switches to track hosts joining and leaving groups and control the flooding of multicast traffic on the local VLAN.  This should be enabled on all switches where multicast services are enabled, if it is not done by default.

IPv6 multicast over a routed connection

IPv6 multicast has benefited from the lessons learned during the development of IPv4 multicast and is much more straightforward to configure and operate.  The protocols required are different, but configured and operate in much the same way as their IPv4 counterparts, so will not be described separately.

  • IPv6 PIM is used on the links between the networks to handle group joins and leaves.  It is also used internally, by each network (the CUDN and the institution), to provide the RPs.  Note that IPv6 PIM operates only in Sparse Mode and is simply referred to as "IPv6 PIM", or colloquially "PIMv6".
  • MBGP is used to exchange Reverse Path Forwarding (RPF) routes.
  • Multicast Listener Discovery (MLD) replaces IGMP on edge subnets to allow hosts to join and leave groups and is snooped by switches to control flooding on a local subnet.  MLD version 1 is largely analogous to IGMPv2 and MLD version 2 to IGMPv3.

Note that there is no equivalent of MSDP: inter-domain multicast routing is handled through the use of Source Specific Multicast or Embedded RP.

Multicast group address allocation

When sending traffic, the choice of group address depends on the desired audience of the traffic: some groups are constrained to the CUDN, whilst others can reach across the global internet.

The organisation of group addresses differs significantly between IPv4 and IPv6 and so they are described separately.

IPv4 group addresses and scope

IPv4 multicast group addresses are allocated from the block 224.0.0.0/4.  As with IPv4 unicast the CUDN has a number of globally-routable IPv4 multicast group addresses, as well as some with a more limited scope where global reachability is either undesirable or unnecessary.

The prefix 239.0.0.0/8 was assigned by IANA for administratively-scoped multicast group addresses, with blocks in this space further defined by the IETF in RFC 2365.  For Janet and the CUDN, this range is divided into a number of blocks: semi-privateCUDN-wide private and institution-private.  All other addresses in this range are connected to Janet and the internet but should be considered "reserved"

ScopeBlockRegistryPurpose
Global 232.0.0.0/8 (none) Source Specific Multicast (SSM) defined in RFC 4607
233.3.18.0/8 Janet(UK) Internet-wide group addresses according to RFC 2770 ("GLOP" range), based on AS numbers
234.128.232.0/24 Computer Laboratory Internet-wide group addresses according to RFC 6034, based on unicast prefixes
234.129.169.0/24 Engineering
234.131.111.0/24 (UCS) IP Register
234.192.18.195 Medical Research Council
234.192.84.5 (UCS) IP Register
234.192.153.213
Semi-private 239.192.0.0/14 Janet(UK) Janet-wide education and research
239.194.0.0/16 * GÉANT Pan-European research and education on the GÉANT network
CUDN-wide private 239.252.0.0/15 (UCS) IP Register CUDN-wide services
239.254.0.0/16 Institutions
Institution-private 239.255.0.0/16 Institution Institution local services (single CUDN connection)

* note that 239.194.0.0/16 is part of 239.192.0.0/14 and is excluded from the latter.

It should be noted that group address assignments allow the registry to designate their use.  Other parties can then use the group as defined — this may mean that sources and/or receivers of that group need not be in that registry's organisation.

Global IPv4 group addresses using All Sources Multicast (ASM)

234.0.0.0/8 has been allocated by IANA for Unicast Prefix-Based IPv4 Multicast Addresses, with the policy defined by the IETF in RFC 6034.  This gives holders of IPv4 unicast address prefix p.q.r.x a block of multicast group addresses in the block 234.p.q.r.  For the CUDN, this gives 234.128.232.0/24, 234.129.169.0/24 and 234.131.111.0/24 and a number of single addresses corresponding to /24 allocations to individual institutions.

This allocation does not automatically transfer down onto the end institution on the CUDN.  For example, just because an institution has 131.111.10.0/23 it does not mean they automatically have a right to use 234.131.111.10/31; allocations within these blocks must be directed to the appropriate registry within the University.

The RFC does not state whether this allocation method is to be automatically extended to assignments of Provider Aggregateable (PA) address space to end sites.  Janet has also not published a policy on this, so it must be assumed that allocations from such space are NOT available to the CUDN.  These include: 234.193.60.80/28 (corresponding to 193.60.80.0/20) and 234.193.63.252/31 (193.63.252.0/23).

233.0.0.0/8 has been allocated for AS number-based addresses (so-called "GLOP" addresses), with the policy documented in RFC 2770.  This allocates /24 blocks of group addresses based on the global AS number of a network.  The CUDN does not have a global number itself but is part of the Janet network — AS786 — yielding the block 233.(786 DIV 256).(786 MOD 256).0/24 = 233.3.18.0/24.  Addresses in this block must be requested via IP Register from Janet(UK), prior to use.

Global IPv4 group addresses using Source Specific Multicast (SSM)

The CUDN supports Source Specific Multicast (SSM) on the unicast prefix-based IANA-reserved range for this (232.0.0.0/8), as defined in RFC 4607.

SSM requires that first hop routers handle sources and receivers in this range correctly by supporting PIM Source Specific Multicast (PIM-SSM), as well as support IGMP version 3.  If the remote end is not on the CUDN (or is an institution on the CUDN which does not support it) SSM will not work.

Semi-private IPv4 group addresses

239.192.0.0/14 is defined as "organizational local scope" in RFC 2365.  In the context of Janet, the "organisation" is defined as Janet and all connected institutions (of which the CUDN is one).  Group addresses in this range are allocated by Janet(UK) and do not pass outside the Janet network and could be considered "Janet-private group addresses".

One exception to this is 239.194.0.0/16, which is allowed to cross to other networks that are part of GÉANT, the pan-European education and research network. Group addresses in this range could be considered to be "GÉANT-private group addresses".

CUDN-wide private IPv4 group addresses

239.252.0.0/14 is defined as "site local scope" in RFC 2365 (with the recommendation that allocation be started from 239.255.0.0/16 and work downwards into the /14 only once the top /16 is no longer sufficient).  In the context of Janet, the "site" is a Janet-connected institution (e.g. the CUDN).  Group addresses in this range will not be routed across the Janet network between sites and so can be considered to be "CUDN-wide private group addresses".

This range is further divided on the CUDN into three blocks:

  • 239.252.0.0/15 is for CUDN-wide services with blocks allocated by IP Register for specific, permanent, purposes where 239.254.0.0/16 is inappropriate due to insufficient capacity, potentially temporary nature, or an institution not having any such addresses available (due to the lack of any address space in 131.111.0.0/16).
  • 239.254.0.0/16 is suitable for semi-permanent purposes - an institution is entitled to use 239.254.r.s where they have the corresponding address 131.111.r.s assigned to them.  For example, if an institution has 131.111.10.0/23, they can use the group addresses in 239.254.10.0/23.
  • 239.255.0.0/16 is for groups private to an individual institutional network and is explained separately.

Note that the entitlement to addresses in 239.254.0.0/16 ends if the corresponding allocation in 131.111.0.0/16 is rescinded.  If an institution requires more permanent addresses they should contact IP Register for an allocation in 239.252.0.0/15.  Also note that the entitlement to use these addresses is given to the institution and not the individual end-user who might have a specific address — an institution may wish to pass on this entitlement, but this is determined by the policy of that institution.

All CUDN-wide private group addresses, including those in 239.254.0.0/16, must be registered with IP Register before they are used.  The block of group addresses allocated must first be assigned to the institution and then individual group addresses registered.

For institutions with dynamic routed link connections, sources for groups in the CUDN-wide private group address range will be accepted over the MSDP peering with the CUDN router and redistributed across the CUDN (including to other institutions with MSDP peerings) but will not be advertised to Janet.

Institution-private IPv4 group addresses

As stated above239.255.0.0/16 is defined as "site local scope".  In the context of the CUDN, for this /16 the boundary is an individual institutional connection to the CUDN:

  • For edge subnets routed directly by CUDN routers, traffic using these addresses will not cross into the CUDN backbone, or between VLANs belonging to the same institution at that or other sites.  Note that communication between hosts using different subnets on the same VLAN will work, regardless of the netmask in use, as that does not pass through the CUDN router (unlike most unicast traffic).
  • Institutions with internal routers can route traffic using these group addresses internally, but it will be blocked at the uplink to the CUDN.  In addition, sources for groups in this range sent over an MSDP peering with a CUDN router will be rejected.

Institutions are encouraged to use this range for VLAN-local services (typically using a TTL of 1); this will avoid consuming resources in the CUDN multicast routing tables (unlike addresses elsewhere in 239.252.0.0/14) and should be the default choice for things such as failover cluster groups.  Various local service groups, including that used by UPnP (239.255.255.250), already fit within this range and thus will be contained within a VLAN.

Addresses in the institution-private range do not need registering with IP Register.  However, institutions will likely need to maintain a register of these allocations to ensure they're unique across the appropriate scope.

IPv6 group addresses and scopes

IPv6 multicast addresses are allocated from the block ff00::/8 and has a much cleaner structure — in particular, the larger IP address space allows the group address to include the scope (which administrative boundaries the traffic will cross) and a block of address space to be automatically assigned to owners of unicast address prefixes (much like 234.0.0.0/8 does for IPv4).

There are three main types of IPv6 group address:

The 'M' above represents the scope of the group, specifying which administrative boundaries the traffic will cross.  The defined scopes are:

ScopeIETF definitionMeaning on CUDN / Janet
3 Subnet-local Subnet / VLAN
4 Admin-local Administrative scope within an institution
5 Site-local Institution (e.g. department or college) — no traffic with this scope or lower will cross into the CUDN backbone
8 Organisation-local CUDN (including institutions with their own AS within the CUDN)
e Global-local Internet

It should be noted the scopes are an intrinsic part of the group address and not an additional attribute: two group addresses which differ only by their scope are distinct groups which must be sent to or joined separately.

In the future, additional scopes may be defined (e.g. '7' to refer to part of the CUDN, or 'd' for pan-European research networks).  The determination of scope boundaries needs consensus amongst all connected parties for a consistent implementation and reliable operation; in the meantime, scopes undefined in the table above should generally not be used.

Global IPv6 group addresses using All Sources Multicast (ASM) and Embedded RP

Because IPv6 multicast does not use MSDP, or an equivalent, there is no way for a multicast router to know the global sources of multicast traffic for a particular group, elsewhere on the internet.  Instead, for All Sources Multicast (ASM), a technique whereby the Rendezvous Point (RP) address is contained within the group address is used, known as Embedded RP.

Embedded RP uses addresses in the block ff70::/12 and structured in the following manner:

Unicast prefix

Embed RPScopeRsvdI'face IDPrefix length

CUDN prefix

(= RP Network Prefix)

Inst prefixGroup ID
12 bits 4 bits 4 bits 4 bits 8 bits 44 bits 12 bits 40 bits
ff7 M : 0 a 2c : 2001:0630:021 J:KL QR:STUV:WXYZ
/12 /16 /20 /24 /32 /76 /88 /128

The address of the RP is constructed from the RP Network Prefix and Interface ID, as shown:

RP Network PrefixInterface ID
44 bits (= 2C hex = Prefix length) 4 bits
2001:0630:0210 :: a

2001:630:210::a is an anycast address of the CUDN-provided embedded RP.  This address is provided redundantly by multiple routers so is protected against the failure of any particular router.

This arrangement gives an institution with a /56 allocation (the standard on the CUDN) 40 bits (~ 1 trillion) for group addresses using the CUDN Embedded RP, as shown above.  For example, St Botolph's College, with a unicast allocation of 2001:630:212:300::/56, have ff7M:a2c:2001:630:212:300::/88 available to use.

Institutions may also choose to run their own Embedded RPs on their CUDN address space (assuming the correct routing protocol configuration).  In this situation, the RP Network Prefix length will change to '38' (in hex = 56 decimal).  For example, St Botolph's College may use group addresses ff7M:a38:2001:630:212:300::/88 (i.e. ff7M:a38:2001:630:212:3QR:STUV:WXYZ), giving an Embedded RP address of 2001:630:212:300::a (the final nibble could obviously be changed to any value, but generally should not be the real address of any particular device but one dedicated for Embedded RP).

Global IPv6 group addresses using Source Specific Multicast (SSM)

When using Source Specific Multicast (SSM), the unicast address of the source is specified by the group member and RPs are not used.  Such addresses are in ff3M::/96 (i.e. ff3M:0000:0000:0000:0000:0000:STUV:WXYZ, with the final 32 bits available for the group address).

SSM requires that the first hop router supports MLD version 2 but is typically supported by all IPv6 PIM routers.

CUDN PIM domain-wide IPv6 group addresses using All Sources Multicast (ASM)

Within a PIM domain, there is a single PIM RP and so All Sources Multicast (ASM) can be used without the need to specify the RP or source host, much the same as traditional IPv4 multicast.  As there is no MSDP, groups will be limited to the local PIM domain and groups outside will not be joined, nor traffic forwarded to them.

There two sorts of such addresses:

  • ff3M:00KL::/32 is for unicast prefix-based group addresses are ones assigned by the institution for local use
  • ff00::/12 (with various scopes) are assigned by IANA for specific uses

For both of these, only one scope is supported in the CUDN PIM domain: 8 (= organisation-local = CUDN-wide) — scopes smaller than this would only span an institution or subnet and scopes larger would span greater than the CUDN (e.g. Janet or the internet).  However, this address type does not work across PIM domains and cannot be administratively scoped lower on the CUDN backbone, so scope 8 is the only one which make sense.

The unicast prefix-based group addresses are structured as follows on the CUDN:

Unicast prefix
Local ASMScopeReservedPrefix lengthCUDN prefixInst prefixGroup ID
12 bits 4 bits 8 bits 8 bits 44 bits 12 bits 40 bits
ff3 M : 00 2c : 2001:0630:021 J:KL QR:STUV:WXYZ
/12 /16 /24 /32 /76 /88 /128

For example, St Botolph's College (with unicast prefix 2001:630:212:300::/56) can use group addresses in ff38:2c:2001:630:212:300::/88 (i.e. ff38:2c:2001:630:212:3QR:STUV:WXYZ) for ASM multicast within the CUDN AS only.

Important note: institutions with their own PIM domains (typically those running BGP to connect to the CUDN) will be in a distinct PIM domain and will not be able to connect with the CUDN using these groups as they use a separate RP, even with organisation-local scope (8).  Such institutions must use one of the global schemes - Embedded RP or SSM for groups which extend onto the CUDN or global internet.  For the local PIM domain, ASM multicast should use groups in the range ff35:38:2001:630:21P:QR00::/88 (with scope 5 = site-local = institution) - e.g. ff35:38:2001:630:212:300::/88 for St Botolph's College.

Filtering of groups on an institutional connection

A number of IPv4 group addresses are blocked at the boundary between the CUDN and an institutional network, preventing traffic from flowing (either being sent or joining groups).  This effectively makes those groups private to a particular institutional connection.  These groups are:

Group address / blockPurpose
224.0.0.251 Multicast DNS (mDNS) inc. Apple Bonjour
224.0.1.1 NTP
224.0.1.2 SGI Dogfight
224.0.1.3 rwhod
224.0.1.8 SUN NIS+
224.0.1.20 Any private experiment
224.0.1.22 Service Location Protocol - Service Agent (SVRLOC)
224.0.1.24 Microsoft Directory Services (Microsoft-DS)
224.0.1.25 NBC-Pro
224.0.1.35 Service Location Protocol - Directory Agent (SVRLOC-DA)
224.0.1.38 Retrospect
224.0.1.39 Cisco Auto-RP Announce
224.0.1.40 Cisco Auto-RP Discovery
224.0.1.60 HP Device Discovery
224.0.1.65 Inter-Access Point Protocol (IAPP)
224.0.1.76
224.0.2.1 rwho
224.0.2.2 Sun RPC
224.0.2.3 Epson Discovery
224.0.23.1 Ricoh Discovery / Device Control
224.0.23.2
224.1.0.1 Cisco Aironet
224.1.0.38 Retrospect
224.2.0.2/31 Altiris Rapideploy
224.77.0.0/16 Symantec (Norton) Ghost
224.101.101.101 Sun Sunray
225.1.2.3 Altiris Deployment Server and Agent
226.77.0.0/16 Symantec (Norton) Ghost
229.55.150.208
234.42.42.40/30 Phoenix/StorageSoft ImageCast Disk Duplication
234.142.142.42/31
234.142.142.44/30
234.142.142.48/28
234.142.142.64/26
234.142.142.128/29
234.142.142.136/30
234.142.142.140/31
234.142.142.142
239.255.0.0/16 The institution-private block

Groups may be added to or removed from this list as new protocols are developed, based on recommendations from Janet(UK), the IETF (in particular draft-chown-mboned-multicast-filtering-02), best practice and local observations.

In addition to the above list, some groups may be filtered for internal security or policy reasons (such as groups from the CUDN-wide ranges being used privately by institutions and inaccessible to the general CUDN).

In IPv6, there is no such filtering as the scope will correctly limit such traffic.

Filtering of groups within institutional networks

Institutions may need to apply filtering of groups internally to apply security policies on the CUDN (e.g. not allowing a private group used for an infrastructure service network to be accessible on a general user network).

In the vast majority of cases, this is not necessary. However, if it is, the institution will be notified of the required filtering.

TTLs

TTLs are often used in multicast as a way to control how far traffic will will reach across the network (and internet).  There are no definitive rules on what these values should be and a TTL should not be used to control scope - administratively-scoped addresses (IPv4) or scopes (IPv6) are generally a much better choice for this.

However, for IPv4 there are some protocols (e.g. SAP, using group address 224.2.127.254) where this is not possible, as a well-known group address must be used.  The CUDN border routers with Janet will not forward traffic out of the CUDN if the TTL is below 16 by the time it reaches them.  A TTL of 15 should be sufficient to reach all areas of the CUDN and is the recommended value to constrain traffic from leaving the CUDN using global group addresses.

The following table gives recommendations for minimum TTLs for various scopes of distribution:

Minimum TTLScope
1 Local VLAN only
15 CUDN and connected institutions
63 Janet and GÉANT
127 Global internet

For IPv6, the TTLs described above are recommended minimums but not administratively enforced.  The scopes embedded into IPv6 group addresses render explicit TTLs unnecessary. 

CUDN-wide private unicast IP addresses

Hosts with CUDN-wide private IPv4 unicast addresses can both source and receive groups with addresses in the CUDN-wide private range across the CUDN.

Traffic to global groups can also be sourced by these hosts, but that traffic will be constrained to the CUDN.  They can also join global groups but they are not guaranteed to receive such traffic from sources outside the CUDN.  Because of these restrictions, it is not recommended that hosts with CUDN-wide private unicast addresses use global groups.

Transition during 2013

The configuration of multicast services on the CUDN is changing during spring/summer 2013 to the configuration described above.  The following table summarises the main changes and the current status of each.

Prior to changesAfter changesCurrent state
Single RP for all groups Multiple RPs, split for different sets of groups  Implemented
Non-redundant RP Redundant RPs Implemented
Non-redundant PIM BSR Redundant PIM BSR Implemented
No PIM BSR/RP flltering PIM BSR/RP filtering on edge connections Implemented
Routed institutional peerings using PIM-SM and CUDN RPs Routed institutional peerings using MSDP and institutional RPs Implemented
No public group allocation Global group allocations in 234.0.0.0/8 Implemented
239.0.0.0/8 defined as CUDN-wide private Only 239.252.0.0/14 defined as CUDN-wide private; supporting 239.192.0.0/14 to Janet Implemented
No institution-private range 239.255.0.0/16 defined as institution-private Implemented
No filtering of local VLAN-only groups Filtering of assorted groups Implemented
No outbound minimum TTL threshold on Janet connection Outbound minimum TTL threshold of 16 on Janet connection Implemented
SSM unsupported SSM supported Implemented
IGMP version 2 IGMP version 3 (with fallback to version 2, if required) Implemented
IPv6 multicast unavailable IPv6 multicast available and supported Implemented
IPv6 intradomain All Sources Multicast (ASM) unavailable IPv6 All Sources Multicast (ASM) available and supported for hosts on the CUDN backbone Partially implemented (parts of the network remain disabled to work around issues with client operating systems)
IPv6 intra- and inter-domain Source Specific Multicast (SSM) unavailable IPv6 Source Specific Multicast (SSM) available and supported for intra- and inter-domain (including Janet/internet) sources and members Implemented
IPv6 embedded RP not available IPv6 embedded RP available and supported with redundant anycast RP Implemented
IPv6 multicast via BGP not available IPv6 multicast via BGP available and supported Implemented
No IPv6 group addressing scheme IPv6 group addressing scheme determined and published Implemented

Last modified: 17 August 2016

Contact

If you have any enquiries regarding UIS network services, or other University network topics, please send an email to: