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 University Data Network (UDN) backbone supports multicast internally and to and from the global internet. Support in individual institutions connected to the UDN 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 UDN 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.
Contents
- Support on institutional connections
- Multicast group address allocation and scope
- Filtering of groups on an institutional connection
- TTLs
- UDN-wide private unicast IP addresses
- Troubleshooting
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 UDN 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 UDN routers, IPv4 multicast routing to the UDN and beyond can be enabled just by making a request to Network Support. Once enabled, multicast to and from the UDN 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 UDN 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 UDN 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 a BGP peering with the UDN 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 UDN 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
IPv4 multicast via routed institutional networks uses a number of protocols:
- Protocol Independent Multicast - Sparse Mode (PIM-SM) is used on the links between the networks to handle group joins and leaves. It is also used internally, by each network (the UDN and the institution) to route traffic between the routers within the institutional network provides the Rendezvous Point(s) (RPs).
- Multiprotocol BGP (MBGP) is used to exchange Reverse Path Forwarding (RPF) routes between PIM domains (the UDN and the institution).
- Multicast Source Discovery Protocol (MSDP) is used to exchange information about active multicast sources between PIM domains.
- Internet Group Multicast Protocol (IGMP) is used by hosts to signal the router and intermediate switches that they wish to join or leave groups.
Each of these protocols is described below, along with how they are configured on the UDN.
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 UDN routers. PIM Sparse-Dense Mode (PIM-SDM) should typically NOT be used and certainly not on the uplinks to the UDN: the UDN 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 UDN, 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 UDN 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 UDN router between the same IP addresses used for the BGP peering (i.e. the UDN and institution ends of the router links): institutions must configure MSDP to peer with the UDN router using these addresses to receive SA messages.
If an institution has multiple routers peering with the UDN, or an RP router which is inside their network (i.e. not one of the ones peering directly with the UDN), then they must run MSDP internally, as appropriate.
SAs will be filtered over the institutional peering with the UDN 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 UDN filters UDN-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 UDN 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 UDN, 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 UDN 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 UDN, this range is divided into a number of blocks: semi-private, UDN-wide private and institution-private. All other addresses in this range are connected to Janet and the internet but should be considered "reserved".
| Scope | Block | Registry | Purpose |
|---|---|---|---|
| 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 | Jisc | Janet-wide education and research |
| 239.194.0.0/16 * | GÉANT | Pan-European research and education on the GÉANT network | |
| UDN-wide private | 239.252.0.0/15 | (UCS) IP Register | UDN-wide services |
| 239.254.0.0/16 | Institutions | ||
| Institution-private | 239.255.0.0/16 | Institution | Institution local services (single UDN 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 UDN, 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 UDN. 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 UDN. 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 UDN does not have a global number itself but is part of the Janet network — AS786 — yielding the block 233.(786 / 256).(786 % 256).0/24 = 233.3.18.0/24 [where '/' = integer division and '%' = modulo]. 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 UDN 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 UDN (or is an institution on the UDN 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 UDN is one). Group addresses in this range are allocated by Jisc 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".
UDN-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 UDN). Group addresses in this range will not be routed across the Janet network between sites and so can be considered to be "UDN-wide private group addresses".
This range is further divided on the UDN into three blocks:
- 239.252.0.0/15 is for UDN-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 UDN-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 UDN-wide private group address range will be accepted over the MSDP peering with the UDN router and redistributed across the UDN (including to other institutions with MSDP peerings) but will not be advertised to Janet.
Institution-private IPv4 group addresses
As stated above, 239.255.0.0/16 is defined as "site local scope". In the context of the UDN, for this /16 the boundary is an individual institutional connection to the UDN:
- For edge subnets routed directly by UDN routers, traffic using these addresses will not cross into the UDN 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 UDN 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 UDN. In addition, sources for groups in this range sent over an MSDP peering with a UDN 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 UDN 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:
- Global All Sources Multicast (ASM) with Embedded RP — ff7M::/12
- Global Source Specific Multicast (SSM) — ff3M::/96
- UDN PIM domain-wide using All Sources Multicast — ff3M:00KL::/32 and ff0M::/12
The 'M' above represents the scope of the group, specifying which administrative boundaries the traffic will cross. The defined scopes are:
| Scope | IETF definition | Meaning on UDN / 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 UDN backbone |
| 8 | Organisation-local | UDN (including institutions with their own AS within the UDN) |
| 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 UDN, 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 RP | Scope | Rsvd | I'face ID | Prefix length |
UDN prefix (= RP Network Prefix) |
Inst prefix | Group ID | ||||
| 12 bits | 4 bits | 4 bits | 4 bits | 8 bits | 32 bits | 16 bits | 48 bits | ||||
| ff7 | M | : | 0 | a | 20 | : | 2a05:b400 | : | IJKL | : | OPQR:STUV:WXYZ |
| /12 | /16 | /20 | /24 | /32 | /64 | /80 | /128 | ||||
The address of the RP is constructed from the RP Network Prefix and Interface ID, as shown:
| RP Network Prefix | Interface ID | |
|---|---|---|
| 32 bits (= 20 hex = Prefix length) | 4 bits | |
| 2a05:b400 | :: | a |
2a05:b400::a is an anycast address of the UDN-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 /48 allocation (the standard on the UDN) 48 (= 128 - 80) bits (just over 280 trillion) for group addresses using the UDN Embedded RP, as shown above. For example, St Botolph's College, with a unicast allocation of 2a05:b400:130::/48, have ff7M:a20:2a05:b400:130::/80 available to use.
Institutions may also choose to run their own Embedded RPs on their UDN address space (assuming the correct routing protocol configuration). In this situation, the RP Network Prefix length will change to '30' (in hex = 48 decimal). For example, St Botolph's College may use group addresses ff7M:a30:2a05:b400:130::/80 (i.e. ff7M:a30:2a05:b400:130:OPQR:STUV:WXYZ), giving an Embedded RP address of 2a05:b400:130::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.
UDN 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 equivalent of 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 UDN PIM domain: 8 (= organisation-local = UDN-wide) — scopes smaller than this would only span an institution or subnet and scopes larger would span greater than the UDN (e.g. Janet or the internet). However, this address type does not work across PIM domains and cannot be administratively scoped lower on the UDN backbone, so scope 8 is the only one which make sense.
The unicast prefix-based group addresses are structured as follows on the UDN:
| Unicast prefix | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Local ASM | Scope | Reserved | Prefix length | UDN prefix | Inst prefix | Group ID | ||||
| 12 bits | 4 bits | 8 bits | 8 bits | 32 bits | 16 bits | 40 bits | ||||
| ff3 | M | : | 00 | 20 | : | 2a05:b400 | : | IJKL | : | OPQR:STUV:WXYZ |
| /12 | /16 | /24 | /32 | /64 | /80 | /128 | ||||
For example, St Botolph's College (with unicast prefix 2a05:b400:130::/48) can use group addresses in ff30:20:2a05:b400:130::/80 (i.e. ff30:20:2a05:b400:130:OPQR:STUV:WXYZ) for ASM multicast within the UDN AS only.
Important note: institutions with their own PIM domains (typically those running BGP to connect to the UDN) will be in a distinct PIM domain and will not be able to connect with the UDN 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 UDN or global internet. For the local PIM domain, ASM multicast should use groups in the range ff35:30:2a05:b400:IJKL::/80 (with scope 5 = site-local = institution) - e.g. ff35:30:2a05:b400:130::/80 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 UDN 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 / block | Purpose |
|---|---|
| 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 UDN-wide ranges being used privately by institutions and inaccessible to the general UDN).
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 UDN (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 UDN border routers with Janet will not forward traffic out of the UDN 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 UDN and is the recommended value to constrain traffic from leaving the UDN using global group addresses.
The following table gives recommendations for minimum TTLs for various scopes of distribution:
| Minimum TTL | Scope |
|---|---|
| 1 | Local VLAN only |
| 15 | UDN 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.
UDN-wide private unicast IP addresses
Hosts with UDN-wide private IPv4 unicast addresses can both source and receive groups with addresses in the UDN-wide private range across the UDN.
Traffic to global groups can also be sourced by these hosts, but that traffic will be constrained to the UDN. They can also join global groups but they are not guaranteed to receive such traffic from sources outside the UDN. Because of these restrictions, it is not recommended that hosts with UDN-wide private unicast addresses use global groups.
Troubleshooting multicast
Problems with multicast can be extremely difficult to diagnose for a number of reasons, especially when it works intermittently, or stops after a few minutes. The primary reason for this is multicast is very temporal — unlike unicast routes, which tend to exist in the network even when a host is not actively transmitting or receiving traffic, a multicast flow only appears when it is active and must be refreshed periodically, with routers and switches maintaining a number of timers to remove it, when the sender or receiver have gone away.
To assist the UIS in diagnosing multicast issues, you can help by doing the following things:
- State the sending and receiving (member) unicast addresses, along with the multicast group addresses.
- State whether multicast has ever worked between the sender and receiver and if anything has changed recently. Note that most networks on the UDN are NOT enabled for multicast by default.
- If it [partially] works now, or starts and stops; if it starts and stops, what the intervals are between this happening (a few seconds, minutes, or the flow is jittery).
- Leave the sender and receiver active, whilst the UIS investigates the issue. If these are stopped, or data is switched to unicast as a workaround, this makes it very difficult to see what is going wrong as the flow will not appear in the network to examine.
- Remember that the UIS do not typically understand specific software applications: if something isn't working, the fault will need to be explained in terms of what the application is doing with multicast underneath. This may involve UIS Networks liaising with the supplier or support partner for the affected software.
Aside from multicast problems themselves, don't forget that multicast traffic is always UDP and will suffer from the same problems as any other UDP traffic: if there is congestion or loss on a link, especially compared to TCP transfers. It may simply be that the network is congested between the sender and receiver(s). Most software should contain statistical information to help explain these issues (such as 'packets lost' or 'packets arrived too late').
Last modified: 30th January 2023