• Home   /  
  • Archive by category "1"

Sntp Multicast Address Assignment

Internet Protocol (IP) multicasting is the sending of a single datagram to multiple hosts on a network or internetwork. Of the three delivery methods supported by IP, multicasting is the method that is most practical for one-to-many delivery. Unlike IP multicasting, IP unicasting sends a separate datagram to each recipient host. IP broadcasting sends a single datagram to all hosts on a single network segment (also known as subnet), even to those not interested in receiving it. Recent trends toward multimedia applications such as video conferencing necessitate the use of multicasting to efficiently send traffic to multiple hosts.

Before sending or receiving IP multicast data, a network must be enabled for multicasting, as follows:

This document describes how multicasting works in an IPv4 network. In addition to IPv4, the Windows Server 2003 family includes the latest version of IP, known as IP version 6 (IPv6). For information about how multicasting works with IPv6, see “IPv6 Technical Reference.”

To support multicasting in an internetwork, the hosts and routers must be multicast-enabled. In an IP multicast-enabled intranet, any host can send IP multicast datagrams, and any host can receive IP multicast datagrams, including sending and receiving across the Internet.

The source host sends multicast datagrams to a single Class D IP address, known as the group address. Any host that is interested in receiving the datagrams contacts a local router to join the multicast group and then receives all subsequent datagrams sent to that address.

Routers use a multicast routing protocol to determine which subnets include at least one interested multicast group member and to forward multicast datagrams only to those subnets that have group members or a router that has downstream group members. The IP header of a multicast datagram includes a Time-to-Live (TTL) value that determines how far routers can forward a multicast datagram.

The following figure shows how multicasting components fit in an internetwork.

IP Multicasting Architecture

In this illustration, the following is occurring:

  1. Host A in Subnet 1 is the multicasting source and is sending multicast data to the multicast group address.

  2. Host B in Subnet 1 has requested group membership from its local router. Because Host B has joined the multicast group, its network adapter is listening for datagrams sent to the multicast group address. The remaining host in Subnet 1 has not requested group membership, so its network adapter is filtering out traffic sent to the multicast group address.

  3. Routers forward multicast data to any subnet that has group members or a router that has downstream group members. In this example, the routers are forwarding multicast data from Subnet 1 to Subnet 3. The data is also sent across Subnet 2, although it has no group members, because there are downstream group members.

  4. Host C in Subnet 3 has requested group membership and is also receiving the multicast data.

  5. Host D in Subnet 3 is sending a request to its local router to join the group. After Host D joins the group, its network adapter will also listen for traffic sent to the multicast group address.

Alternatively, multicast data might come from the multicast-enabled portion of the Internet, known as the MBone.

The following table introduces the multicasting components, which are described later in this section.

IP Multicasting Components

Component Description

Host (source or receiver)

A host is any client or server on the network. A multicast-enabled host is configured to send and receive (or only send) multicast data.

Router

A multicast router is capable of handling host requests to join or leave a group and of forwarding multicast data to subnets that contain group members. A multicast router can be either a non-Microsoft router that uses a multicast routing protocol or a Windows Server 2003-based server running the Routing and Remote Access service.

Multicast address

A Class D IP address used for sending IP multicast data. An IP multicast source sends the data to a single multicast address, as described later in this section. A specific IP multicast address is also known as a group address.

Multicast group

A multicast group is the set of hosts that listen for a specific IP multicast address. A multicast group is also known as a host group.

MBone

The Internet multicast backbone, or the portion of the Internet that supports multicast routing.

Host

On a multicast-enabled network, a host that is configured to send multicast data can send datagrams to a single designated Class D IP address so that multiple hosts can receive the data. A host that is configured to receive multicast data can use IGMP to join a multicast group and then listen for datagrams sent to the multicast address. Hosts can send and receive multicast data from anywhere on an intranet or the Internet.

A host supports IP multicasting at one of the following levels:

  • Level 0 - No support for sending or receiving IP multicast datagrams.

  • Level 1 - Supports sending but not receiving IP multicast datagrams.

  • Level 2 - Supports both sending and receiving IP multicast datagrams.

TCP/IP for Windows Server 2003 (as well as Windows XP) supports all levels of IP multicasting and, by default, is configured for Level 2 support. You can modify the level of support by changing the IGMPLevel subkey under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ in the registry.

Note

  • It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution.

Router

The role of a multicast router is to:

  • Manage multicast group membership by processing IGMP requests to join or leave groups.

  • Forward multicast traffic to subnets of the internetwork that contain multicast group members.

Multicast routing is more complex than unicast routing. The following table compares the characteristics of unicast routing and multicast routing.

Unicast Routing and Multicast Routing Comparison

Unicast Routing Characteristics Multicast Routing Characteristics

Unicast traffic is sent to a globally unique destination.

Multicast traffic is sent to an ambiguous group destination.

Unicast routes in the routing table summarize ranges of globally unique destinations.

Because group addresses represent different groups with different members, group addresses generally cannot be summarized in the IP multicast forwarding table.

Unicast routes are comparatively consistent, so the routing table needs to be updated only when the topology of the internetwork changes. Unicast routing protocols update the unicast routing table.

The location of group members is not consistent, so the IP multicast forwarding table might need to be updated whenever a group member joins or leaves a multicast group. Multicast routing protocols update the IP multicast forwarding table.

Multicast routers can be hardware or software routers. Non-Microsoft routers that are multicast-enabled run a multicast routing protocol, such as one of the following:

  • Distance Vector Multicast Routing Protocol (DVMRP)

  • Multicast Extensions to Open Shortest Path First (MOSPF)

  • Protocol Independent Multicast (PIM)

These protocols are briefly described later in this document. These protocols are not included with Windows Server 2003.

Windows Server 2003 Routing and Remote Access can be used for multicast forwarding. The Routing and Remote Access service includes an IGMP routing protocol component that uses two modes, router mode and proxy mode, to add entries to the TCP/IP multicast forwarding table. Because Routing and Remote Access is not designed to replace a true multicast routing protocol, it supports several specific configurations, which are described later in this document.

Multicast Addresses

IP addresses in the Class D range are reserved for IP multicasting. Class D addresses are in the range of 224.0.0.0 to 239.255.255.255, with the four high-order bits always set to 1110. In network prefix or classless interdomain routing (CIDR) notation, IP multicast addresses are summarized as 224.0.0.0/4.

Within the Class D range of addresses, certain ranges of multicast addresses have special meaning, as follows:

  • Addresses in the range of 224.0.0.0 to 224.0.0.255 (224.0.0.0/24) are reserved for local subnet multicast traffic. Datagrams sent to addresses in this range are not forwarded by IP routers.

  • Addresses in the range of 224.0.1.0 to 238.255.255.255 are known as globally scoped addresses, which means they can be used for multicasting across an intranet or the Internet. Some addresses within this range are reserved by the Internet Assigned Numbers Authority (IANA) for special purposes.

  • Addresses in the range of 239.0.0.0 to 239.255.255.255 (239.0.0.0/8) are reserved for administratively scoped addresses. Administratively scoped addresses as defined by RFC 2365 are used to prevent the forwarding of multicast traffic across boundaries configured for the address. Multicast boundaries are described in more detail later in this document.

The following are examples of reserved IP multicast addresses:

  • 224.0.0.1 - All hosts on this subnet

  • 224.0.0.2 - All routers on this subnet

  • 224.0.0.5 - Open Shortest Path First (OSPF) version 2, designed to reach all OSPF routers

  • 224.0.0.6 - OSPF version 2, designed to reach all OSPF-designated routers and designated backup routers

  • 224.0.0.9 - Routing Information Protocol (RIP) version 2

  • 224.0.1.1 - Network Time Protocol

For the latest list of reserved multicast addresses, see the IANA link.

MAC-Level Multicast Addresses

As described previously, a multicast datagram is sent to a single group address, and only members of the group receive the datagram. For a network adapter to receive a multicast datagram, the IP multicast address must be mapped to a hardware, or media access control (MAC), multicast address. The network adapter then listens for any datagrams that are addressed to this MAC-level address and passes the datagrams up to the operating system.

The Internet Assigned Numbers Authority (IANA) has reserved a range of multicast addresses for Ethernet and Fiber Distributed Data Interface (FDDI) networks. The following table lists the MAC-level multicast addresses used for different types of networks.

MAC-Level Multicast Addresses

Network Type Multicast Addresses Related RFC

Ethernet and FDDI

0x01-00-5E-00-00-00 to 0x01-00-5E-7F-FF-FF

1112

Token Ring

0xC0-00-00-04-00-00

1469

Token Ring can use the same method of MAC-level multicast addressing as Ethernet and FDDI, but many Token Ring network adapters do not support it. By default, therefore, all IP multicast addresses on Token Ring networks are mapped to the single functional address specified in the preceding table. You can modify the use of this functional address by editing the TrFunctionalMcastAddress subkey under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ in the registry. IP multicasting on Token Ring network adapters is supported for Windows 2000, Windows XP, and the Windows Server 2003 family.

Note

  • It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution.

IP Multicast to MAC-Level Multicast Address Mapping

To map an IP multicast address to a MAC-level multicast address, the 23 low-order bits of the IP multicast address are mapped directly to the 23 low-order bits of the MAC-level multicast address. The 25 high-order bits in the MAC-level multicast address are fixed. The following figure illustrates how the IP multicast address is mapped to the MAC-level multicast address.

IP Multicast Address Mapped to Ethernet or FDDI MAC Address

This figure also illustrates the following:

  • The 4 high-order bits of the IP multicast address are fixed according to the Class D address definition.

  • The 5 remaining bits (bits 5 to 9) in the IP multicast address are not mapped to the MAC-level multicast address, so the resulting MAC address is not unique. This means that it is possible for a host to receive MAC-level multicast datagrams for up to 32 groups to which it does not belong. However, IP drops datagrams that do not match a multicast address that is registered by an application or another protocol.

  • The low-order bit of the first octet in a MAC-level destination address is the Individual/Group bit. This bit is set to 0 for a unicast or individual address and to 1 for a multicast address or a broadcast address.

Example of MAC-level address mapping

If the IP multicast address is 224.192.16.1, the MAC-level multicast address becomes 0x01-00-5E-40-10-01, as illustrated in the following figure.

Sample Address Mapping

The 23 low-order bits in the IP multicast address map directly to the MAC-level multicast address. Because the entire third and fourth octets are included in the mapping, they can be converted directly to hexadecimal. The high-order bit of the second octet is dropped from the mapping, so that octet must be converted to binary first. In this example, dropping the high-order bit results in a value of 1000000, which converts to decimal 64 and hexadecimal 0x40. The shading in the figure shows that the 25 high-order bits of the MAC-level multicast address are fixed values.

Multicast Groups

The set of hosts listening for a specific IP multicast address is called a multicast group or a host group. Multicast groups have the following attributes:

  • Group membership is dynamic; hosts can join and leave the group at any time.

  • Members of a group can be located anywhere on a multicast-enabled network.

  • A host need not be a member of a multicast group to send data to the group’s IP multicast address.

  • Group members can receive both unicast and multicast traffic.

  • A host can be a member of any number of multicast groups.

  • A multicast group has no size limits.

  • Multicast groups can be either transient or permanent. Permanent groups are assigned a well-known multicast address. For example, multicast address 224.0.0.1 is a permanent address for the all-hosts multicast group. Membership in a permanent group is transient; only the address is permanent.

MBone

The MBone, or Internet multicast backbone, is the portion of the Internet that supports the forwarding of Internet-based IP multicast traffic. The MBone, used in conjunction with tunneling, provides a way for multicast traffic to travel across portions of the Internet that do not support multicasting.

Tunneling is the encapsulation of a datagram within another datagram. For multicast traffic to traverse the Internet, each IP multicast datagram must be encapsulated within an IP unicast datagram, which is known as IP-in-IP tunneling. An IP-in-IP tunnel is used to forward information between endpoints in an IP internetwork that have differing capabilities, thus acting as a logical link between the endpoints. The encapsulating IP header includes the addresses of the endpoints as the source and destination addresses. The following figure illustrates an encapsulated IP datagram.

IP-in-IP Datagram Structure

The MBone consists of a series of multicast-enabled islands. These islands are collections of contiguous networks that use routers that support multicast routing. IP-in-IP tunneling allows the multicast traffic to travel from one island to another. The IP header of the unicast datagram is addressed from a router in one multicast-enabled island to a router in another multicast-enabled island.

The MBone is used for audio and video multicasts of Internet Engineering Task Force (IETF), the National Aeronautics and Space Administration, and the United States House of Representatives and Senate meetings, among other uses. Support for the MBone can vary among Internet service providers (ISPs).

A variety of protocols are used for various aspects of IP multicasting. The following table briefly identifies the protocols described in this section.

Protocols Used for IP Multicasting

Protocol Description RFC

IGMP

Internet Group Management Protocol. Hosts use this protocol to make group membership requests. Routers use this protocol to query for active group members in a subnet. (Note: IPv6 uses Multicast Listener Discovery (MLD) instead of IGMP to manage group membership.)

1112

DVMRP

Distance Vector Multicast Routing Protocol. This is a multicast routing protocol.

1075

MOSPF

Multicast Extensions to Open Shortest Path First. This is a multicast routing protocol.

1584

PIM

Protocol-Independent Multicast. This is a multicast routing protocol.

2117

MADCAP

Multicast Address Dynamic Client Allocation Protocol. This protocol enables a host to request an IP multicast address from a multicast address allocation server.

2730

PGM

Pragmatic General Multicast. PGM is a reliable multicast transport protocol. Typically, multicast datagrams are delivered by using UDP, which is an inherently unreliable transport protocol. Hosts and routers that are PGM-enabled can recover lost multicast datagrams.

3208

IGMP

Internet Group Management Protocol (IGMP) maintains host group membership on a local subnet. Hosts use IGMP to communicate multicast group membership requests with their local multicast router. Routers receive the group membership requests and periodically send out queries to determine which host groups are active or inactive on the local subnet. This protocol is required to support Level 2 multicasting.

IGMP messages are encapsulated in IP datagrams and use IP protocol number 0x02. The following illustrates the resulting datagram.

Encapsulated IGMP Message

There are three versions of IGMP:

  • IGMP version 1 is provided by TCP/IP for Microsoft Windows NT Server 4.0 Service Pack 3 and earlier.

  • IGMP version 2 is provided by TCP/IP for Microsoft Windows NT Server 4.0 Service Pack 4 and later and Windows 2000. Routers using this version are backward-compatible with hosts using IGMP version 1.

  • IGMP version 3 is provided by TCP/IP for Windows XP and Windows Server 2003. Routers using this version are backward-compatible with hosts using IGMP version 2 or IGMP version 1. Hosts running Windows XP or Windows Server 2003 use IGMP version 3 by default. To configure a host running Windows XP SP2 or later to use IGMP version 1 or IGMP version 2, use the IGMPVersion subkey under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ in the registry.

    Note

    • It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution.

This section describes the differences between the three versions of IGMP.

IGMP Version 1

IGMP version 1 consists of the following two types of messages:

  • Host Membership Report

  • Host Membership Query

The following table describes the fields in IGMP version 1 messages.

Fields in IGMP Version 1 Messages

IGMP Version 1 Field Length Description

Version

4 bits

Identifies the IGMP version. It is set to 1.

Type

4 bits

Identifies the type of message:

  • 0x1 for Host Membership Query

  • 0x2 for Host Membership Report

Unused

1 octet

Set to 0 by sender, ignored by receiver.

Checksum

2 octets

Used to test for data transmission errors.

Group Address

4 octets

Specifies the group address for the type of message:

  • 0.0.0.0 for Host Membership Query

  • The multicast group address to be joined for Host Membership Report

Host Membership Report

To join a multicast group, a host sends an IGMP Host Membership Report message to the specific group address, regardless of whether other hosts on the subnet are already multicast group members. Unlike a multicast router, a host does not keep track of the multicast group membership of other hosts on its subnet. A multicast router uses a special listening mode called multicast promiscuous mode so that it can receive all IP multicast traffic. Because it listens in multicast promiscuous mode, a multicast router receives and processes IGMP Host Membership Report messages that are sent to any multicast address.

Host Membership Query

An IGMP version 1 multicast router (known as a multicast query router) periodically sends an IGMP Host Membership Query message to IP address 224.0.0.1 (the all-hosts group) to obtain updated information about multicast group membership on the subnet. The multicast routing protocols determine which router is to send the query messages.

Multicast routers do not need to track the specific hosts that belong to a group, but only that at least one host in a subnet belongs to the group. For each multicast group that has members on the subnet, one multicast group member responds with an IGMP Host Membership Report message. To keep multiple hosts on a particular subnet from sending IGMP Host Membership Report messages for the same group, a random response timer on the hosts delays the transmission of the IGMP Host Membership Report message. If another host on the same subnet sends a message before the response timer expires, a host does not send its own message.

Addresses and TTLs used for IGMP version 1 messages

The following table summarizes the values of the source and destination IP addresses in the IP header, the TTL in the IP header, and the Group Address in the IGMP header for the two types of IGMP version 1 messages.

Addresses and TTLs Used for IGMP Version 1 Messages

Address IGMP Host Membership Report IGMP Host Membership Query

Source IP address (IP header)

<HostInterfaceIPAddress>

<RouterInterfaceIPAddress>

Destination IP address (IP header)

<GroupAddress>

224.0.0.1

TTL

1

1

Group address

<GroupAddress>

0.0.0.0

IGMP version 1 has no explicit mechanism for hosts to notify a router that it is ready to leave a multicast group.

For more information about IGMP version 1, see Appendix I of RFC 1112 in the IETF RFC Database.

IGMP Version 2

IGMP version 2 extends the functionality of IGMP version 1 by including the following:

  • A procedure for determining which router in a subnet is to be the multicast query router

  • A new message for when hosts leave a multicast group

  • A new group-specific query message

  • A new version of the Host Membership Report

The following table describes the fields in IGMP version 2 messages.

Fields in IGMP Version 2 Messages

IGMP Version 2 Field Length Description

Type

1 octet

Identifies the type of message:

  • 0x11 for Host Membership Query

  • 0x12 for IGMP version 1 Host Membership Report

  • 0x16 for IGMP version 2 Host Membership Report

  • 0x17 for Leave Group Message

Maximum Response Time

1 octet

Specifies the maximum allowable time (in tenths of a second) for a host to respond to a router query. Used only in query messages.

For Routing and Remote Access routers, this value is configured with the Query response interval from either of the following sources:

  • Routing and Remote Access Microsoft Management Console (MMC) snap-in Router tab for the IGMP interface properties

  • Netsh routing ip igmp set interface command

Checksum

2 octets

Used to test for data transmission errors.

Group Address

4 octets

Specifies the group address for the type of message:

  • 0.0.0.0 for general Host Membership Query message

  • The specific multicast group address for Group-Specific Host Membership Query, Host Membership Report, and Leave Group messages

Note

  • The Version field is eliminated and the Type field is 8 bits in IGMP version 2. The hexadecimal value of the Type field in version 2 messages is the result of concatenating the version 1 hexadecimal values of the Version field (0x1) and the Type field (0x1 for Host Membership Query and 0x2 for Host Membership Report).

Query router election

In contrast to IGMP version 1, in which the multicast routing protocols determine the multicast query router, IGMP version 2 uses a simple election process to choose one router on each subnet to send the periodic IGMP Host Membership Query messages. The elected router is the one with the numerically lowest IP address. During the election process, each router listens for IGMP queries from other routers. If a router receives a query with a lower source IP address, that router does not send multicast queries. If a router does not receive a query with a lower source IP address, it becomes the multicast query router for the subnet.

Leave Group message

The Leave Group message reduces leave latency, which is the time it takes for a multicast router to stop forwarding multicast traffic to a subnet that no longer contains multicast group members. If a host responds to the last IGMP query, it might be the last or only member of the multicast group. When this host leaves the group, it sends an IGMP Leave Group message to the all-routers multicast group (224.0.0.2). Upon receipt of the Leave Group message, the router sends a series of group-specific queries to the multicast group. If no host responds to the group-specific queries, the router determines that the multicast group on that subnet contains no members.

IGMP group-specific query

An IGMP Host Membership Query is sent to 224.0.0.1 (the all-hosts group) to find out which multicast groups have members on the subnet. IGMP version 2 routers can also send a group-specific query to a specific group address to find out if that group has any members on the subnet.

IGMP version 2 Host Membership Report

The IGMP version 2 Host Membership Report has the same function as the IGMP version 1 Host Membership Report, except that it is used by IGMP version 2 routers.

Addresses and TTLs used for IGMP version 2 messages

The following table summarizes the values of the source IP address, the destination IP address and the TTL in the IP header, as well as the value of the Group Address in the IGMP header for the two additional types of IGMP version 2 messages.

Addresses and TTLs Used for IGMP Version 2 Messages

Address IGMP Leave Group Message IGMP Group-Specific Query

Source IP address (IP header)

<HostInterfaceIPAddress>

<RouterInterfaceIPAddress>

Destination IP address (IP header)

224.0.0.2

<GroupBeingQueried>

TTL

1

1

Group address

<GroupBeingLeft>

<GroupBeingQueried>

For more information about IGMP version 2, see RFC 2236 in the IETF RFC Database.

IGMP Version 3

IGMP version 3 extends the functionality of IGMP version 2 by adding support for source filtering, also known as source-specific multicasting. With IGMP version 3, it is possible to have multiple sources for a multicast data stream so that hosts can join the group and receive the data from the nearest source. For example, you might use this feature for an organization-wide video conference. You can have multiple sources multicast the video conference and place the sources in different regions so that hosts can join the group and specify the source topologically nearest them.

IGMP version 3 has a modified version of the Host Membership Query message and includes a new version of the Host Membership Report.

Source filtering

Source filtering is the ability of a host to specify that it receive multicast traffic only from specific source addresses. With IGMP version 1 and IGMP version 2, a host reports group membership regardless of the source of the multicast traffic sent to its group. If multicast traffic is sent to a group from multiple sources, a subnet with a group member receives one multicast datagram from each source.

IGMP version 3 allows a host to specify either of the following for a particular multicast group:

  • The sources from which it is to receive messages pertaining to the group (a list of included sources).

  • The sources from which it is not to receive messages pertaining to the group (a list of excluded sources).

Multicast routers and multicast routing protocols use the source-specific information in the IGMP version 3 Host Membership Report message to prevent forwarding and delivering multicast messages from specific sources to subnets that have no interested group members.

IGMP version 3 Host Membership Query

The IGMP version 3 Host Membership Query message has the same Type value and the same format as the IGMP version 2 Host Membership Query message, except that it includes additional fields after the Group Address field. The additional fields provide query parameters for routers and specify the included or excluded sources for the multicast group being queried. The list of included or excluded sources is used only for queries to a specific group that uses source filtering.

The first 8 octets of the IGMP version 3 Host Membership Query message are the same as IGMP version 2. The Type value for the modified Host Membership Query remains 0x11. The following table describes the fields in IGMP version 3 Host Membership Query messages.

Fields in IGMP Version 3 Host Membership Query Messages

IGMP Version 3 Field Length Description

Type

1 octet

Identifies the type of message:

  • 0x11 for Host Membership Query

Maximum Response Time

1 octet

Specifies the maximum allowable time (in tenths of a second) for a host to respond to a general (not group-specific) router query.

For Routing and Remote Access routers, this value is configured with the Query response interval from either of the following sources:

  • Routing and Remote Access snap-in Router tab for the IGMP interface properties

  • Netsh routing ip igmp set interface command

Checksum

2 octets

Used to test for data transmission errors.

Group Address

4 octets

Specifies the group address for the query message:

  • 0.0.0.0 for general Host Membership Query

  • The specific multicast group address for Group-Specific Host Membership Query, Host Membership Report, and Leave Group

Reserved

4 bits

Set to 0 by sender, ignored by receiver.

Suppress Router-Side Processing

1 bit

Set to 1 to specify that receiving routers are to suppress normal timer updates when they receive a query.

Querier’s Robustness Variable (QRV)

3 bits

Allows tuning for expected datagram loss on the network. IGMP can recover QRV-1 lost datagrams.

For Routing and Remote Access routers, this value is configured with the Robustness variable from either of the following sources:

  • Routing and Remote Access snap-in Router tab for the IGMP interface properties

  • Netsh routing ip igmp set interface command

Querier’s Query Interval Code

1 octet

Specifies how many seconds the router waits between general queries.

For Routing and Remote Access routers, this value is configured with the Query interval from either of the following sources:

  • Routing and Remote Access snap-in Router tab for the IGMP interface properties

  • Netsh routing ip igmp set interface command

Number of Sources

2 octets

Specifies the number of source addresses included in the query message.

Source Addresses

4 octets per address

Specifies the IP addresses of multicast sources.

IGMP version 3 Host Membership Report

A host uses the IGMP version 3 Host Membership Report message to specify all the multicast groups it wants to join, and for each group address, either the sources from which it is to receive multicast data (the list of included sources) or the sources from which it is not to receive multicast data (the list of excluded sources).

The IGMP version 3 Host Membership Report message contains a series of group records. Each record contains the multicast group address and the associated list of sources. The Host Membership Report message is sent to the multicast address 224.0.0.22, which is a reserved multicast address for all IGMP version 3-capable multicast routers.

The following table describes the fields in IGMP version 3 Host Membership Report messages.

Fields in IGMP Version 3 Host Membership Report Messages

IGMP Version 3 Field Length Description

Type

1 octet

Identifies the type of message:

  • 0x12 for IGMP version 1 Host Membership Report

  • 0x16 for IGMP version 2 Host Membership Report

  • 0x22 for IGMP version 3 Host Membership Report

Reserved

1 octet

Set to 0 by sender, ignored by receiver.

Checksum

2 octets

Used to test for data transmission errors.

Reserved

2 octets

Set to 0 by sender, ignored by receiver.

Number of Records

2 octets

Specifies the number of group records in the message.

Group Records

Variable

Each record specifies the IP address for a multicast group being joined or left and a list of included or excluded sources.

Addresses and TTLs used for IGMP version 3 messages

The following table summarizes the values of the source and destination IP addresses, the TTL in the IP header, and the value of the Group Address in the IGMP header for the two additional types of IGMP version 3 messages.

Addresses and TTLs Used for IGMP Version 3 Messages

Address IGMP Host Membership Query for Specific Groups and Sources IGMP Host Membership Report

Source IP address (IP header)

<RouterInterfaceIPAddress>

<HostInterfaceIPAddress>

Destination IP address (IP header)

<GroupBeingQueried>

224.0.0.22

TTL (IP header)

1

1

Group address (IGMP header)

<GroupBeingQueried>

<GroupAddress> in individual group address records

For more information about IGMP version 3, see RFC 3376 in the IETF RFC Database.

Multicast Routing Protocols: DVMRP, MOSPF, and PIM

The goals of multicast routing protocols include the following:

  • Forward traffic away from the source to prevent loops.

  • Minimize or eliminate multicast traffic to subnets that do not need to receive it.

  • Minimize CPU and memory load on the router for scalability.

  • Minimize the traffic overhead of a routing protocol.

  • Minimize the join latency, which is the time it takes for the first group member on a subnet to begin receiving group traffic.

Multicast routing protocols use a variety of algorithms to create efficient multicast delivery paths through the internetwork. Unicast routers use the IP destination address to forward traffic toward the destination. Because multicast traffic is sent to a group address, multicast routers use the source address to forward traffic away from the source to avoid looping the traffic back to the source.

This section provides a brief introduction to the most common multicasting routing protocols. These protocols are not provided with Windows Server 2003.

Distance Vector Multicast Routing Protocol (DVMRP)

DVMRP is a multicast routing protocol that grew from Routing Information Protocol (RIP), a unicast routing protocol that forwards datagrams based on information about the next hop toward the destination. In contrast to RIP, DVMRP forwards datagrams based on information about the previous hop back toward the source.

DVMRP builds a delivery tree for determining where to forward datagrams. It floods the first multicast datagrams to a multicast group across the internetwork and then prunes the branches of the tree that lead to subnets that do not include group members.

DVMRP is most efficient in environments where multicast group members are densely distributed over the internetwork. DVMRP runs on internetworks with multicast routers and also supports tunneling (encapsulating multicast datagrams within a unicast datagram for forwarding through non-multicast routers). DVMRP does not scale well.

Multicast Extensions to OSPF (MOSPF)

MOSPF is a multicast routing protocol that is an extension to Open Shortest Path First (OSPF). This protocol builds a delivery tree for determining where to forward datagrams by using group membership information from IGMP and the OSPF link-state database. The trees are built on demand for each source-group pair.

MOSPF is intended for use on a single organization’s network and does not scale well. MOSPF requires OSPF as its accompanying unicast routing protocol. It can sometimes put a heavy load on router CPU bandwidth.

MOSPF is most efficient in environments where multicast group members are densely distributed over the internetwork. It does not support tunneling but can work in multicast environments with non-MOSPF routers.

Protocol-Independent Multicast (PIM)

PIM consists of two protocols: PIM Dense Mode (PIM-DM) and PIM Sparse Mode (PIM-SM). PIM-DM is most efficient in environments where multicast group members are densely distributed over the internetwork. PIM-SM is most efficient in environments where group members are sparsely distributed. A multicast group that uses PIM can declare itself sparse or dense.

The PIM protocol establishes routes to multicast groups whose members span wide-area and interdomain internetworks. PIM functions independently of any specific unicast routing protocol, although it does use the existing unicast routing table.

PIM-DM

This protocol is designed for multicast groups whose members are distributed densely over an area where bandwidth is plentiful. Like DVMRP, PIM-DM first floods multicast traffic across the internetwork and then prunes the subnets that have no group members.

PIM-DM is interoperable with PIM-SM. PIM-DM does not scale well.

PIM-SM

PIM-SM is the most widely used multicast routing protocol. It is designed for multicast groups with members distributed sparsely across a large region and is most efficient in a WAN environment. The flood-and-prune method used by PIM-DM can cause unnecessary traffic. In contrast, PIM-SM forwards multicast traffic only to routers that explicitly request it. With PIM-SM, routers must explicitly join and leave multicast groups to receive or stop receiving multicast traffic.

MADCAP

Multicast Address Dynamic Client Allocation Protocol (MADCAP) is a method for hosts to request a multicast address from a multicast address allocation server. If multiple hosts use the same IP multicast address for different applications, multicast traffic can be forwarded to the incorrect group members. MADCAP prevents this problem by allocating unique multicast addresses. It supports dynamic assignment and configuration of IP multicast addresses on TCP/IP-based networks.

MADCAP is an extension of the Dynamic Host Configuration Protocol (DHCP) standard, but is separate from DHCP. The Windows Server 2003 DHCP service supports both DHCP and MADCAP, but the functions are independent.

Multicast administrative scopes configured on the DHCP server define ranges of IP multicast addresses. Unique IP multicast addresses are allocated to a single DHCP client, similar to how unique unicast IP addresses are assigned to clients.

For more information about MADCAP and its support in Windows Server 2003, see “DHCP Technical Reference.” For more information about the IETF definition of MADCAP, see RFC 2730 in the IETF RFC Database.

PGM

Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for multicast-enabled applications that require properly sequenced, duplicate-free delivery of datagrams. Typically, multicast datagrams are sent as UDP datagrams, but UDP is inherently unreliable because it does not guarantee packet delivery or retransmit lost packets. PGM ensures that a host that is a member of a multicast group either receives all the transmitted datagrams or detects unrecoverable lost datagrams. It is implemented on both source and destination hosts.

IPv4 Multicast Address Space Registry

Last Updated
2018-02-20
Expert(s)
Stig Venaas
Note
Host Extensions for IP Multicasting [RFC1112] specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. The multicast addresses are in the range 224.0.0.0 through 239.255.255.255. Address assignments are listed below. The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive, is reserved for the use of routing protocols and other low-level topology discovery or maintenance protocols, such as gateway discovery and group membership reporting. Multicast routers should not forward any multicast datagram with destination addresses in this range, regardless of its TTL.
Available Formats

XML
HTML
Plain text

Registries included below

Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24))

Registration Procedure(s)
Expert Review, IESG Approval, or Standards Action
Reference
[RFC5771]
Note
(*) It is only appropriate to use these values in explicitly- configured experiments; they MUST NOT be shipped as defaults in implementations. See [RFC3692] for details.
Available Formats

CSV

Internetwork Control Block (224.0.1.0 - 224.0.1.255 (224.0.1/24))

Registration Procedure(s)
Expert Review, IESG Approval, or Standards Action
Reference
[RFC5771]
Available Formats

CSV

AD-HOC Block I (224.0.2.0 - 224.0.255.255)

Registration Procedure(s)
Expert Review, IESG Approval, or Standards Action
Reference
[RFC5771]
Available Formats

CSV
Address(es)DescriptionReferencesChange ControllerDate RegisteredLast Reviewed
224.0.2.0Unassigned
224.0.2.1"rwho" Group (BSD) (unofficial)[Jon_Postel]
224.0.2.2SUN RPC PMAPPROC_CALLIT[Brendan_Eic]
224.0.2.3EPSON-disc-set[SEIKO_EPSON_Corp]2005-01-01
224.0.2.4All C1222 Nodes[RFC6142]2009-08-28
224.0.2.5Monitoring Discovery Protocol[Alan_Robertson]2012-04-17
224.0.2.6BitSend MediaStreams[Carl-Johan_Sjöberg]2012-04-25
224.0.2.7-224.0.2.8rxWARN[Caleb_Bell]2012-11-19
224.0.2.9DATV streams[Grant_Taylor]2016-10-04
224.0.2.10swapapp_multicast[Applykane]2017-05-19
224.0.2.11-224.0.2.63Unassigned
224.0.2.64-224.0.2.95Intercontinental Exchange, Inc.[RIR_Admin]1996-042007-07
224.0.2.96-224.0.2.127BallisterNet[Tom_Ballister]1997-07-01
224.0.2.128-224.0.2.191WOZ-Garage[Douglas_Marquardt]1997-02-01
224.0.2.192-224.0.2.255Intercontinental Exchange, Inc.[RIR_Admin]1997-02-01
224.0.3.0-224.0.3.255RFE Generic Service[Daniel_Steinber]
224.0.4.0-224.0.4.255RFE Individual Conferences[Daniel_Steinber]
224.0.5.0-224.0.5.127CDPD Groups[[Bob Brenner]]
224.0.5.128-224.0.5.191Intercontinental Exchange, Inc.[RIR_Admin]1998-10-01
224.0.5.192-224.0.5.255Intercontinental Exchange, Inc.[RIR_Admin]2001-08-01
224.0.6.0-224.0.6.127Cornell ISIS Project[[Tim Clark]]
224.0.6.128-224.0.6.143MoeSingh[Moe_Singh]2009-09-24
224.0.6.144QDNE[Architecture_Team]2018-01-03
224.0.6.145-224.0.6.150Unassigned
224.0.6.151Canon-Device-control[Hiroshi_Okubo]2014-08-01
224.0.6.152-224.0.6.191Unassigned
224.0.6.192-224.0.6.255OneChicago multicast[Brian_Trudeau]2014-09-19
224.0.7.0-224.0.7.255Where-Are-You[Bill_Simpson]1994-11-01
224.0.8.0Cell broadcast encapsulation[Meridian_Labs_LTD][LIRNEasia]2017-10-13
224.0.8.1-224.0.8.255Unassigned
224.0.9.0-224.0.9.255The Thing System[Carl_Malamud]1998-04-01
224.0.10.0-224.0.10.255DLSw Groups[Choon_Lee]1996-04-01
224.0.11.0-224.0.11.255NCC.NET Audio[David_Rubin]1996-08-01
224.0.12.0-224.0.12.63Microsoft and MSNBC[Tom_Blank]1996-11-01
224.0.13.0-224.0.13.255WorldCom Broadcast Services[Tony_Barber]1997-01-01
224.0.14.0-224.0.14.255NLANR[Duane_Wessels]1997-02-01
224.0.15.0-224.0.15.255Agilent Technologies[IP_Admin]1997-02-01
224.0.16.0-224.0.16.255XingNet[Mika_Uusitalo]1997-04-01
224.0.17.0-224.0.17.31Mercantile & Commodity Exchange[Asad_Gilani]1997-07-01
224.0.17.32-224.0.17.63NDQMD1[Michael_Rosenberg]1999-03-01
224.0.17.64-224.0.17.127ODN-DTV[Richard_Hodges]1999-03-01
224.0.18.0-224.0.18.255Dow Jones[Wenjie_Peng]1997-01-01
224.0.19.0-224.0.19.63Walt Disney Company[Scott_Watson]1997-08-01
224.0.19.64-224.0.19.95Cal Multicast[Ed_Moran]1997-10-01
224.0.19.96-224.0.19.127Intercontinental Exchange, Inc.[RIR_Admin]1997-102007-07
224.0.19.128-224.0.19.191IIG Multicast[Wayne_Carr]1997-12-01
224.0.19.192-224.0.19.207Metropol[James_Crawford]1998-05-01
224.0.19.208-224.0.19.239Xenoscience, Inc.[Mary_Timm]1998-07-01
224.0.19.240-224.0.19.255MJDPM[Matthew_Straight]2007-03-01
224.0.20.0-224.0.20.63MS-IP/TV[Tony_Wong]1998-07-01
224.0.20.64-224.0.20.127Reliable Network Solutions[Werner_Vogels]1998-08-01
224.0.20.128-224.0.20.143TRACKTICKER Group[Alan_Novick]1998-08-01
224.0.20.144-224.0.20.207CNR Rebroadcast MCA[Robert_Sautter]1999-08-01
224.0.21.0-224.0.21.127Talarian MCAST[Geoff_Mendal]1999-01-01
224.0.22.0-224.0.22.239WORLD MCAST[Ian_Stewart]1999-06-01
224.0.22.240-224.0.22.255Jones International[Jim_Ginsburg]2007-10-31
224.0.23.0ECHONET[Takeshi_Saito]2003-02-01
224.0.23.1Ricoh-device-ctrl[Akihiro_Nishida]2003-02-01
224.0.23.2Ricoh-device-ctrl[Akihiro_Nishida]2003-02-01
224.0.23.3-224.0.23.10Telefeed[Wally_Beddoe]2003-04-01
224.0.23.11SpectraTalk[Madhav_Karhade]2003-05-01
224.0.23.12EIBnet/IP[Marc_Goossens]2003-07-01
224.0.23.13TVE-ANNOUNCE2[Michael_Dolan]2003-10-01
224.0.23.14DvbServDisc[Bert_van_Willigen]2004-01-01
224.0.23.15-224.0.23.31MJDPM[Matthew_Straight]2007-03-01
224.0.23.32Norman MCMP[Kristian_A_Bognaes]2004-02-01
224.0.23.33RRDP[Tetsuo_Hoshi]2004-06-01
224.0.23.34AF_NA[Bob_Brzezinski]2005-10-28
224.0.23.35AF_OPRA_NBBO[Bob_Brzezinski]2005-10-28
224.0.23.36AF_OPRA_FULL[Bob_Brzezinski]2005-10-28
224.0.23.37AF_NEWS[Bob_Brzezinski]2005-10-28
224.0.23.38AF_NA_CHI[Bob_Brzezinski]2005-10-28
224.0.23.39AF_OPRA_NBBO_CHI[Bob_Brzezinski]2005-10-28
224.0.23.40AF_OPRA_FULL_CHI[Bob_Brzezinski]2005-10-28
224.0.23.41AF_NEWS_CHI[Bob_Brzezinski]2005-10-28
224.0.23.42Control for IP Video[Nadine_Guillaume]2005-02-01
224.0.23.43acp-discovery[Andy_Belk]2005-02-01
224.0.23.44acp-management[Andy_Belk]2005-02-01
224.0.23.45acp-data[Andy_Belk]2005-02-01
224.0.23.46dof-multicast[Bryant_Eastham]2006-06-162015-04-23
224.0.23.47AF_DOB_CHI[Bob_Brzezinski]2005-10-28
224.0.23.48AF_OPRA_FULL2_CHI[Bob_Brzezinski]2005-10-28
224.0.23.49AF_DOB[Bob_Brzezinski]2005-10-28
224.0.23.50AF_OPRA_FULL2[Bob_Brzezinski]2005-10-28
224.0.23.51Fairview[Jim_Lyle]2006-08-07
224.0.23.52Intercontinental Exchange, Inc.[RIR_Admin]2006-08-11
224.0.23.53MCP[Tim_DeBaillie]2006-11-30
224.0.23.54ServDiscovery[Paul_Langille]2007-01-17
224.0.23.55noaaport1[Antonio_Querubin]2008-02-04
224.0.23.56noaaport2[Antonio_Querubin]2008-02-04
224.0.23.57noaaport3[Antonio_Querubin]2008-02-04
224.0.23.58noaaport4[Antonio_Querubin]2008-02-04
224.0.23.59DigacIP7[Jonathan_Niedfeldt]2008-02-22
224.0.23.60AtscSvcSig[Jerry_Whitaker]2008-12-19
224.0.23.61SafetyNET p (potentially IGMPv1)[Pilz]2009-03-13
224.0.23.62BluemoonGamesMC[Christopher_Mettin]2009-05-12
224.0.23.63iADT Discovery[Paul_Suhler]2009-05-12
224.0.23.64-224.0.23.80Moneyline[Guido_Petronio]2004-01-01
224.0.23.81-224.0.23.127Reserved (Moneyline)
224.0.23.128-224.0.23.157PHLX[Michael_Rosenberg]2004-01-01
224.0.23.158VSCP[Charles_Tewiah]2005-09-01
224.0.23.159LXI-EVENT[Nick_Barendt]2005-11-04
224.0.23.160solera_lmca[Mark_Armstrong]2006-02-09
224.0.23.161VBooster[Alexander_Pevzner]2006-03-17
224.0.23.162cajo discovery[John_Catherino]2006-03-17
224.0.23.163INTELLIDEN[Jeff_Schenk]2006-03-31
224.0.23.164IceEDCP[Oliver_Lewis]2006-07-11
224.0.23.165omasg[Mark_Lipford]2006-07-11
224.0.23.166MEDIASTREAM[Maurice_Robberson]2006-08-15
224.0.23.167Systech Mcast[Dan_Jakubiec]2006-08-21
224.0.23.168tricon-system-management[John_Gabler]2007-07-06
224.0.23.169MNET discovery[Andy_Crick]2008-01-14
224.0.23.170CCNx (not for global routing)[Simon_Barber]2009-09-24
224.0.23.171LLAFP[Michael_Lyle]2009-11-11
224.0.23.172UFMP[Albert_Berlovitch]2010-02-04
224.0.23.173PHILIPS-HEALTH[Anthony_Kandaya]2010-02-26
224.0.23.174PHILIPS-HEALTH[Anthony_Kandaya]2010-02-26
224.0.23.175QDP[Kevin_Gross]2010-03-12
224.0.23.176CalAmp WCP[Pierre_Oliver]2011-06-06
224.0.23.177AES discovery[Kevin_Gross_2]2012-08-28
224.0.23.178JDP Java Discovery Protocol[Florian_Weimer]2013-02-08
224.0.23.179PixelPusher[Jasmine_Strong]2014-06-04
224.0.23.180network metronome[George_Neville-Neil]2014-12-17
224.0.23.181polaris-video-transport[Geoff_Golder]2016-04-19
224.0.23.182-224.0.23.191Unassigned
224.0.23.192-224.0.23.255PINKOTC[Sergey_Shulgin]2008-08-12
224.0.24.0-224.0.24.127AGSC UK VVs[Andrew_Rowley]2006-06-09
224.0.24.128-224.0.24.255EM-MULTI[Soren_Martin_Sorensen]2006-08-07
224.0.25.0-224.0.28.255CME Market Data[Sarunas_Brakauskas]2007-03-22
224.0.29.0-224.0.30.255Deutsche Boerse[Jan_Drwal]2007-03-22
224.0.31.0-224.0.34.255CME Market Data[Sarunas_Brakauskas]2007-07-17
224.0.35.0-224.0.35.255M2S[Itamar_Gilad]2007-08-31
224.0.36.0-224.0.36.255DigiPlay[Robert_Taylor]2016-09-29
224.0.37.0-224.0.38.255LME OMD Addressing[Johnathan_Ryder]2017-03-24
224.0.39.0-224.0.40.255CDAS[Oyvind_H_Olsen]2007-09-12
224.0.41.0-224.0.41.255Intercontinental Exchange, Inc.[RIR_Admin]2007-11-282011-02-15
224.0.42.0-224.0.45.255MEDIAL[Media_Alliance_JSC]2008-01-15
224.0.46.0-224.0.50.255Deutsche Boerse[Jan_Drwal]2008-01-25
224.0.51.0-224.0.51.255ALCOM-IPTV[TV_System_Administrators][Ålands_Telekommunikation_Ab]2008-04-092018-02-20
224.0.52.0-224.0.53.255Euronext[Euronext_Admin]2008-07-232014-11-24
224.0.54.0-224.0.57.255Get - BCN[Arne_Hvidsten]2008-08-20
224.0.58.0-224.0.61.255Intercontinental Exchange, Inc.[RIR_Admin]2008-08-27
224.0.62.0-224.0.62.255BATS[Andrew_Brown]2008-12-24
224.0.63.0-224.0.63.255BATS Trading[Tim_Gorsline]2009-03-13
224.0.64.0-224.0.67.255Euronext[Euronext_Admin]2009-03-132014-11-24
224.0.68.0-224.0.69.255ISE[ISE-Networks]2009-05-12
224.0.70.0-224.0.71.255Intercontinental Exchange, Inc.[RIR_Admin]2009-06-162011-03-01
224.0.72.0-224.0.72.255TMX[Michael_Caravetta][Boris_Garber]2009-08-28
224.0.73.0-224.0.74.255Direct Edge[Javier_Landin]2009-08-28
224.0.75.0-224.0.75.255ISE[ISE-Networks]2010-01-22
224.0.76.0-224.0.76.255Intercontinental Exchange, Inc.[RIR_Admin]2010-02-262011-03-01
224.0.77.0-224.0.77.255Intercontinental Exchange, Inc.[RIR_Admin]2010-02-26
224.0.78.0-224.0.78.255ALCOM-IPTV[TV_System_Administrators][Ålands_Telekommunikation_Ab]2010-03-122018-02-20
224.0.79.0-224.0.81.255ISE[ISE-Networks]2010-08-24
224.0.82.0-224.0.85.255BATS Trading[BATS_Europe_NOC]2011-01-31
224.0.86.0-224.0.101.255Intercontinental Exchange, Inc.[RIR_Admin]2011-02-10
224.0.102.0-224.0.102.127Intercontinental Exchange, Inc.[RIR_Admin]2011-04-13
224.0.102.128-224.0.102.255MVS-IPTV-2[Andrew_Hoyos]2014-06-12
224.0.103.0-224.0.104.255MVS-IPTV[Adam_DeMinter][Andrew_Hoyos]2011-04-20
224.0.105.0-224.0.105.127MIAX Multicast[Ruben_Hernandez]2011-06-06
224.0.105.128-224.0.105.255MVS-IPTV3[Justin_Beaman]2017-12-04
224.0.106.0-224.0.106.255TMX[Michael_Caravetta][Boris_Garber]2011-06-16
224.0.107.0-224.0.108.255Alpha Group[Zaklina_Petkovic]2011-07-13
224.0.109.0-224.0.110.255Zaklina_Petkovic[David_Brett]2011-10-25
224.0.111.0-224.0.111.255VoleraDataFeed[Gerald_Hanweck]2011-10-25
224.0.112.0-224.0.112.255JHB-STOCK-EXCH[Clem_Verwey]2011-12-07
224.0.113.0-224.0.114.255Deutsche Boerse[Jan_Drwal]2011-12-19
224.0.115.0-224.0.115.255TMX[Michael_Caravetta][Boris_Garber]2012-06-12
224.0.116.0-224.0.116.255Intercontinental Exchange, Inc[RIR_Admin]2012-06-19
224.0.117.0-224.0.119.255ISE[ISE-Networks

One thought on “Sntp Multicast Address Assignment

Leave a comment

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *