Difference between revisions of "Multicast IPv6 Address"
m (→Scope Field) |
m |
||
(12 intermediate revisions by the same user not shown) | |||
Line 9: | Line 9: | ||
|CompareIPv4 = 224.0.0.0/4 | |CompareIPv4 = 224.0.0.0/4 | ||
|Desc1 = [http://tools.ietf.org/html/rfc4291#section-2.7 rfc4291 section 2.7] | |Desc1 = [http://tools.ietf.org/html/rfc4291#section-2.7 rfc4291 section 2.7] | ||
− | |||
− | |||
|Explanation = These addresses are used to identify multicast groups. They should only be used as destination addresses, never as source addresses. | |Explanation = These addresses are used to identify multicast groups. They should only be used as destination addresses, never as source addresses. | ||
}} | }} | ||
− | =Multicast Address Format= | + | ==Multicast Address Format== |
The IPv6 Multicast addresses contains two fields describing which kind of Multicast it is. Flag and Scope. | The IPv6 Multicast addresses contains two fields describing which kind of Multicast it is. Flag and Scope. | ||
{| | {| | ||
|[[Image:Multicast IPv6 format.png|left|350px|Thumb|Format of IPv6 Multicast Address]] | |[[Image:Multicast IPv6 format.png|left|350px|Thumb|Format of IPv6 Multicast Address]] | ||
|} | |} | ||
− | ==Flag Field== | + | ===Flag Field=== |
{| | {| | ||
|- | |- | ||
Line 35: | Line 33: | ||
|- | |- | ||
| T ||align="left"| | | T ||align="left"| | ||
− | T = 0 indicates a permanently-assigned | + | T = 0 indicates a permanently-assigned [http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml well-known] multicast address assigned by IANA. |
− | T = 1 indicates a non-permanently-assigned ("transient" or "dynamically" assigned) multicast address. | + | T = 1 indicates a non-permanently-assigned ("transient" or "dynamically" assigned) multicast address. See [http://tools.ietf.org/html/rfc4291#section-2.7 rfc4292] |
|- | |- | ||
| P ||align="left"| | | P ||align="left"| | ||
Line 53: | Line 51: | ||
|} | |} | ||
− | + | ===Scope Field=== | |
− | ==Scope Field== | ||
The Scope field is used to limit the Scope of the Multicast Group. | The Scope field is used to limit the Scope of the Multicast Group. | ||
{| class="wikitable" style="text-align:center" border=1 | {| class="wikitable" style="text-align:center" border=1 | ||
Line 74: | Line 71: | ||
|- | |- | ||
|} | |} | ||
− | === | + | ====Variable Scope Multicast Addresses==== |
− | The "meaning" of a permanently-assigned multicast address is independent of the scope value. For example, if the "NTP servers group" is assigned a permanent multicast address with a group ID of 101 (hex), then | + | The "meaning" of a Variable Scope or permanently-assigned multicast address is independent of the scope value. For example, if the "NTP servers group" is assigned a permanent multicast address with a group ID of FF0x::101 (hex), then |
::FF01::101 means all NTP servers on the same interface (i.e., the same node) as the sender. | ::FF01::101 means all NTP servers on the same interface (i.e., the same node) as the sender. | ||
::FF02::101 means all NTP servers on the same link as the sender. | ::FF02::101 means all NTP servers on the same link as the sender. | ||
::FF05::101 means all NTP servers in the same site as the sender. | ::FF05::101 means all NTP servers in the same site as the sender. | ||
::FF0E::101 means all NTP servers in the Internet. | ::FF0E::101 means all NTP servers in the Internet. | ||
+ | *See [http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml IANA IPv6 Multicast Address Space Registry] | ||
+ | |||
+ | ====Well Known Multicast examples==== | ||
+ | {| class="wikitable" style="text-align:left" border=1 | ||
+ | |+ | ||
+ | |- bgcolor=lightgrey | ||
+ | ! Address !! Scope !! Meaning !! Description | ||
+ | |- | ||
+ | | FF01::1 || Node || All Nodes ||All nodes on the interface-local scope | ||
+ | |- | ||
+ | | FF01::2 || Node || All Routers || All routers on the interface-local scope | ||
+ | |- | ||
+ | | FF02::1 || Link Local || All Nodes || All nodes on the local-link scope | ||
+ | |- | ||
+ | | FF02::2 || Link Local || All Routers || All routers on the link-local scope | ||
+ | |- | ||
+ | | FF05::2 || Site || All Routers || All routers in a site scope | ||
+ | |} | ||
+ | ====Pinging Multicast Addresses==== | ||
+ | In the first example below | ||
+ | By pinging FF02::2 - All Routers on Local-Link - it's seen from the output below that there are two Routers responding | ||
+ | <source lang=cli> | ||
+ | Campus1#<input>ping FF02::2 source vlan 1 repeat 1</input> | ||
+ | Output Interface: <input>vlan 1</input> | ||
+ | Type escape sequence to abort. | ||
+ | Sending 1, 100-byte ICMP Echos to FF02::2, timeout is 2 seconds: | ||
+ | Packet sent with a source address of FE80::218:18FF:FE7C:B440 | ||
+ | |||
+ | Reply to request 0 received from FE80::128C:CFFF:FE96:F76F, 0 ms | ||
+ | Reply to request 0 received from FE80::219:E7FF:FE51:8C0, 0 ms | ||
+ | Success rate is 100 percent (1/1), round-trip min/avg/max = 0/0/0 ms | ||
+ | 2 multicast replies and 0 errors. | ||
+ | </source> | ||
+ | When pinging FF02::1 - All Nodes on Local-Link - it's seen that there are ten Nodes, including the two Routers from previous example. Using Local-Link address as source. | ||
+ | <source lang=cli> | ||
+ | Campus1#<input>ping FF02::1 source vlan 1 repeat 1</input> | ||
+ | Output Interface: <input>vlan 1</input> | ||
+ | Type escape sequence to abort. | ||
+ | Sending 1, 100-byte ICMP Echos to FF02::1, timeout is 2 seconds: | ||
+ | Packet sent with a source address of FE80::218:18FF:FE7C:B440 | ||
+ | |||
+ | Reply to request 0 received from FE80::22CF:30FF:FEF0:C81A, 0 ms | ||
+ | Reply to request 0 received from FE80::22CF:30FF:FEF0:C880, 0 ms | ||
+ | Reply to request 0 received from FE80::250:56FF:FE8B:C, 0 ms | ||
+ | Reply to request 0 received from FE80::250:56FF:FE8B:3E, 0 ms | ||
+ | Reply to request 0 received from FE80::250:56FF:FE8B:2, 0 ms | ||
+ | Reply to request 0 received from FE80::250:56FF:FE8B:32, 0 ms | ||
+ | Reply to request 0 received from FE80::250:56FF:FE8B:36, 0 ms | ||
+ | Reply to request 0 received from FE80::207:E9FF:FE40:ABF, 0 ms | ||
+ | Reply to request 0 received from FE80::128C:CFFF:FE96:F76F, 0 ms | ||
+ | Reply to request 0 received from FE80::219:E7FF:FE51:8C0, 0 ms | ||
+ | Success rate is 100 percent (1/1), round-trip min/avg/max = 0/0/0 ms | ||
+ | 10 multicast replies and 0 errors. | ||
+ | </source> | ||
+ | When pinging with Global Unicast as Source Address, ''some'' of the nodes respond with their Global Unicast Address. Appently | ||
+ | <source lang=cli> | ||
+ | Campus1#<input>ping FF02::1 source 2001:16D8:DD85:139:218:18FF:FE7C:B441 repeat 1</input> | ||
+ | Output Interface: <input>vlan 139</input> | ||
+ | Type escape sequence to abort. | ||
+ | Sending 1, 100-byte ICMP Echos to FF02::1, timeout is 2 seconds: | ||
+ | Packet sent with a source address of 2001:16D8:DD85:139:218:18FF:FE7C:B441 | ||
+ | |||
+ | Reply to request 0 received from 2001:16D8:DD85:139:250:56FF:FE8B:A, 17 ms | ||
+ | Reply to request 0 received from 2001:16D8:DD85:139:20C:29FF:FE36:45B1, 17 ms | ||
+ | Reply to request 0 received from 2001:16D8:DD85:139:21B:21FF:FE52:917D, 17 ms | ||
+ | Reply to request 0 received from 2001:16D8:DD85:139:216:76FF:FE9F:FEF6, 17 ms | ||
+ | Reply to request 0 received from 2001:16D8:DD85:139:214:5EFF:FE67:614A, 17 ms | ||
+ | Reply to request 0 received from 2001:16D8:DD85:139:20C:29FF:FE4C:C0C, 17 ms | ||
+ | Reply to request 0 received from 2001:16D8:DD85:139:4A5B:39FF:FE5A:A7F7, 17 ms | ||
+ | Reply to request 0 received from 2001:16D8:DD85:139:9221:55FF:FEBC:BD97, 17 ms | ||
+ | Success rate is 100 percent (1/1), round-trip min/avg/max = 17/17/17 ms | ||
+ | 8 multicast replies and 0 errors. | ||
+ | </source> | ||
− | =RFC's= | + | ==RFC's== |
[http://tools.ietf.org/html/rfc4291 rfc4291] ''"IP Version 6 Addressing Architecture"'' defines new flags in [http://tools.ietf.org/html/rfc3306 rfc3306] ''"Unicast-Prefix-based IPv6 Multicast Addresses"'' and [http://tools.ietf.org/html/rfc3956 rfc3956] ''"Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address"'' | [http://tools.ietf.org/html/rfc4291 rfc4291] ''"IP Version 6 Addressing Architecture"'' defines new flags in [http://tools.ietf.org/html/rfc3306 rfc3306] ''"Unicast-Prefix-based IPv6 Multicast Addresses"'' and [http://tools.ietf.org/html/rfc3956 rfc3956] ''"Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address"'' | ||
+ | {{Source cli}} |
Latest revision as of 08:33, 13 June 2011
IPv6 Address Type: | Multicast |
Prefix: | ff00::/8 |
Local Routeable: | Yes and No |
Global Routeable: | Yes and No |
Global Unique: | Yes and No |
Example: | FF0E::101 |
IPv4 Equivalent: | 224.0.0.0/4 |
Described in: | rfc4291 section 2.7 |
These addresses are used to identify multicast groups. They should only be used as destination addresses, never as source addresses.
Multicast Address Format
The IPv6 Multicast addresses contains two fields describing which kind of Multicast it is. Flag and Scope.
Flag Field
The flag field consists of four flags. |
|
Flag | Explanation |
---|---|
T |
T = 0 indicates a permanently-assigned well-known multicast address assigned by IANA. T = 1 indicates a non-permanently-assigned ("transient" or "dynamically" assigned) multicast address. See rfc4292 |
P |
P = 0 indicates a multicast address that is not assigned based on the network prefix. P = 1 indicates a multicast address that is assigned based on the network prefix. See rfc3306 |
R |
R = 0 indicates a multicast address that does not embed the address of the RP R = 1 indicates a multicast address that embed an RP (Rendezvous Point) See rfc3956 |
0 | The high-order flag is reserved, and must be initialized to 0. |
Scope Field
The Scope field is used to limit the Scope of the Multicast Group.
Value | Scope | Explanation |
---|---|---|
1 | Interface-Local | Interface-Local scope spans only a single interface on a node and is useful only for loopback transmission of multicast. |
2 | Link Local | Link-Local multicast scope spans the same topological region as the corresponding unicast scope. |
4 | Admin Local | Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration. |
5 | Site Local | Site-Local scope is intended to span a single site. |
8 | Organization Local | Organization-Local scope is intended to span multiple sites belonging to a single organization. |
E | Global | Global span. |
Variable Scope Multicast Addresses
The "meaning" of a Variable Scope or permanently-assigned multicast address is independent of the scope value. For example, if the "NTP servers group" is assigned a permanent multicast address with a group ID of FF0x::101 (hex), then
- FF01::101 means all NTP servers on the same interface (i.e., the same node) as the sender.
- FF02::101 means all NTP servers on the same link as the sender.
- FF05::101 means all NTP servers in the same site as the sender.
- FF0E::101 means all NTP servers in the Internet.
Well Known Multicast examples
Address | Scope | Meaning | Description |
---|---|---|---|
FF01::1 | Node | All Nodes | All nodes on the interface-local scope |
FF01::2 | Node | All Routers | All routers on the interface-local scope |
FF02::1 | Link Local | All Nodes | All nodes on the local-link scope |
FF02::2 | Link Local | All Routers | All routers on the link-local scope |
FF05::2 | Site | All Routers | All routers in a site scope |
Pinging Multicast Addresses
In the first example below By pinging FF02::2 - All Routers on Local-Link - it's seen from the output below that there are two Routers responding
Campus1#<input>ping FF02::2 source vlan 1 repeat 1</input>
Output Interface: <input>vlan 1</input>
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to FF02::2, timeout is 2 seconds:
Packet sent with a source address of FE80::218:18FF:FE7C:B440
Reply to request 0 received from FE80::128C:CFFF:FE96:F76F, 0 ms
Reply to request 0 received from FE80::219:E7FF:FE51:8C0, 0 ms
Success rate is 100 percent (1/1), round-trip min/avg/max = 0/0/0 ms
2 multicast replies and 0 errors.
When pinging FF02::1 - All Nodes on Local-Link - it's seen that there are ten Nodes, including the two Routers from previous example. Using Local-Link address as source.
Campus1#<input>ping FF02::1 source vlan 1 repeat 1</input>
Output Interface: <input>vlan 1</input>
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to FF02::1, timeout is 2 seconds:
Packet sent with a source address of FE80::218:18FF:FE7C:B440
Reply to request 0 received from FE80::22CF:30FF:FEF0:C81A, 0 ms
Reply to request 0 received from FE80::22CF:30FF:FEF0:C880, 0 ms
Reply to request 0 received from FE80::250:56FF:FE8B:C, 0 ms
Reply to request 0 received from FE80::250:56FF:FE8B:3E, 0 ms
Reply to request 0 received from FE80::250:56FF:FE8B:2, 0 ms
Reply to request 0 received from FE80::250:56FF:FE8B:32, 0 ms
Reply to request 0 received from FE80::250:56FF:FE8B:36, 0 ms
Reply to request 0 received from FE80::207:E9FF:FE40:ABF, 0 ms
Reply to request 0 received from FE80::128C:CFFF:FE96:F76F, 0 ms
Reply to request 0 received from FE80::219:E7FF:FE51:8C0, 0 ms
Success rate is 100 percent (1/1), round-trip min/avg/max = 0/0/0 ms
10 multicast replies and 0 errors.
When pinging with Global Unicast as Source Address, some of the nodes respond with their Global Unicast Address. Appently
Campus1#<input>ping FF02::1 source 2001:16D8:DD85:139:218:18FF:FE7C:B441 repeat 1</input>
Output Interface: <input>vlan 139</input>
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to FF02::1, timeout is 2 seconds:
Packet sent with a source address of 2001:16D8:DD85:139:218:18FF:FE7C:B441
Reply to request 0 received from 2001:16D8:DD85:139:250:56FF:FE8B:A, 17 ms
Reply to request 0 received from 2001:16D8:DD85:139:20C:29FF:FE36:45B1, 17 ms
Reply to request 0 received from 2001:16D8:DD85:139:21B:21FF:FE52:917D, 17 ms
Reply to request 0 received from 2001:16D8:DD85:139:216:76FF:FE9F:FEF6, 17 ms
Reply to request 0 received from 2001:16D8:DD85:139:214:5EFF:FE67:614A, 17 ms
Reply to request 0 received from 2001:16D8:DD85:139:20C:29FF:FE4C:C0C, 17 ms
Reply to request 0 received from 2001:16D8:DD85:139:4A5B:39FF:FE5A:A7F7, 17 ms
Reply to request 0 received from 2001:16D8:DD85:139:9221:55FF:FEBC:BD97, 17 ms
Success rate is 100 percent (1/1), round-trip min/avg/max = 17/17/17 ms
8 multicast replies and 0 errors.
RFC's
rfc4291 "IP Version 6 Addressing Architecture" defines new flags in rfc3306 "Unicast-Prefix-based IPv6 Multicast Addresses" and rfc3956 "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address"