Multicast IPv6 Address - Revision history

Heth at 07:33, 13 June 2011

2011-06-13T07:33:35Z

Heth at 04:48, 13 June 2011

2011-06-13T04:48:00Z

Heth: /* Variable Scope Multicast Addresses */

2011-06-13T04:41:44Z

‎Variable Scope Multicast Addresses

Heth: /* Permanent Assigned Multicast Address */

2011-06-13T04:40:56Z

‎Permanent Assigned Multicast Address

Heth: /* Pinging Multicast Addresses */

2011-06-12T15:37:23Z

‎Pinging Multicast Addresses

Heth: /* Pinging Multicast Addresses */

2011-06-12T15:32:18Z

‎Pinging Multicast Addresses

Heth at 15:28, 12 June 2011

2011-06-12T15:28:40Z

Heth: /* RFC's */

2011-06-12T14:58:04Z

‎RFC's

Heth: /* Well Known Multicast examples */

2011-06-12T14:57:50Z

‎Well Known Multicast examples

Heth: /* Multicast examples */

2011-06-12T14:52:42Z

‎Multicast examples

@@ Line 12: / Line 12: @@
 }}
-=Multicast Address Format=
+==Multicast Address Format==
 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]]
 |}
-==Flag Field==
+===Flag Field===
 {|
 |-
@@ Line 51: / Line 51: @@
 |}
-==Scope Field==
+===Scope Field===
 The Scope field is used to limit the Scope of the Multicast Group.
 {|   class="wikitable" style="text-align:center" border=1
@@ Line 71: / Line 71: @@
 |-
 |}
-===Variable Scope Multicast Addresses===
+====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.
@@ Line 79: / Line 79: @@
 *See [http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml IANA IPv6 Multicast Address Space Registry]
-===Well Known Multicast examples===
+====Well Known Multicast examples====
 {| class="wikitable" style="text-align:left" border=1
 |+
@@ Line 151: / Line 151: @@
 </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"''
 {{Source cli}}

@@ Line 9: / Line 9: @@
   |CompareIPv4     =  224.0.0.0/4
   |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.
 }}

@@ Line 79: / Line 79: @@
 ::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===

@@ Line 73: / Line 73: @@
 |-
 |}
-===Permanent Assigned Multicast Address===
+===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.
 ::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===
 {| class="wikitable" style="text-align:left" border=1

@@ Line 110: / Line 110: @@
 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.
+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>
@@ Line 131: / Line 131: @@
 multicast replies and 0 errors.
 </source>
-When pinging with Global Unicast as Source Address, nodes respond with their Global Unicast Address.
+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>

@@ Line 95: / Line 95: @@
 | FF05::2 || Site || All Routers || All routers in a site scope
 |}
-====Pinging FF02::2====
+====Pinging Multicast Addresses====
-Router IPv6 fastethernet 0/1 is Link-local with five other Routers.
+In the first example below
 <source lang=cli>
-IPv6#<input>ping ipv6 FF02::2 source fastEthernet 0/1 repeat 1</input>
+Campus1#<input>ping FF02::2 source vlan 1 repeat 1</input>
-Output Interface: <input>fastethernet0/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::21B:D4FF:FE0F:8CA3
+Packet sent with a source address of FE80::218:18FF:FE7C:B440
-Reply to request 0 received from FE80::21B:D4FF:FE0F:D812, 4 ms
-Reply to request 0 received from FE80::21B:D4FF:FE0F:8AA4, 4 ms
+Reply to request 0 received from FE80::128C:CFFF:FE96:F76F, 0 ms
-Reply to request 0 received from FE80::F225:72FF:FE3B:D6D2, 4 ms
+Reply to request 0 received from FE80::219:E7FF:FE51:8C0, 0 ms
-Reply to request 0 received from FE80::A60C:C3FF:FEE3:E4E6, 4 ms
+Success rate is 100 percent (1/1), round-trip min/avg/max = 0/0/0 ms
-Reply to request 0 received from FE80::128C:CFFF:FE2E:916E, 4 ms
+multicast replies and 0 errors.
 </source>
-====Pinging FF02::1====
+When pinging FF02::1 - All Nodes on Local-Link - it's seen that there are ten Nodes, including the two Routers from previous example.
 <source lang=cli>
+Campus1#<input>ping FF02::1 source vlan 1 repeat 1</input>
-Campus1#<input>ping FF02::1 source vlan 139 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:B441
+Packet sent with a source address of FE80::218:18FF:FE7C:B440
-Reply to request 0 received from FE80::21B:21FF:FE52:917D, 0 ms
+Reply to request 0 received from FE80::22CF:30FF:FEF0:C81A, 0 ms
-Reply to request 0 received from FE80::214:5EFF:FE67:614A, 0 ms
+Reply to request 0 received from FE80::22CF:30FF:FEF0:C880, 0 ms
-Reply to request 0 received from FE80::216:76FF:FE9F:FEF6, 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:A, 0 ms
+Reply to request 0 received from FE80::250:56FF:FE8B:3E, 0 ms
-Reply to request 0 received from FE80::4A5B:39FF:FE5A:A7F7, 0 ms
+Reply to request 0 received from FE80::250:56FF:FE8B:2, 0 ms
-Reply to request 0 received from FE80::20C:29FF:FE4C:C0C, 0 ms
+Reply to request 0 received from FE80::250:56FF:FE8B:32, 0 ms
-Reply to request 0 received from FE80::20C:29FF:FE36:45B1, 0 ms
+Reply to request 0 received from FE80::250:56FF:FE8B:36, 0 ms
-Reply to request 0 received from FE80::9221:55FF:FEBC:BD97, 8 ms
+Reply to request 0 received from FE80::207:E9FF:FE40:ABF, 0 ms
-Reply to request 0 received from FE80::20C:29FF:FE5A:65ED, 42 ms
+Reply to request 0 received from FE80::128C:CFFF:FE96:F76F, 0 ms
-Reply to request 0 received from FE80::200:74FF:FE8F:85F4, 780 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/83/780 ms
+Success rate is 100 percent (1/1), round-trip min/avg/max = 0/0/0 ms
 multicast replies and 0 errors.
 </source>
 =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"''
 {{Source cli}}

← Older revision		Revision as of 14:58, 12 June 2011
Line 137:		Line 137:
	=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}}