< draft-ietf-magma-snoop-03.txt   draft-ietf-magma-snoop-04.txt >
MAGMA Working Group M. Christensen MAGMA Working Group M. Christensen
Internet Draft mjc@jcaps.com Internet Draft mjc@jcaps.com
October 2002 K. Kimball November 2002 K. Kimball
Expiration Date: April 2003 Hewlett-Packard Expiration Date: May 2003 Hewlett-Packard
F. Solensky
Bluejavelin
Considerations for IGMP and MLD snooping switches Considerations for IGMP and MLD snooping switches
<draft-ietf-magma-snoop-03.txt> <draft-ietf-magma-snoop-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026]. all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 46 skipping to change at page 1, line 48
switches. The requirements for IGMPv2 snooping switches are based switches. The requirements for IGMPv2 snooping switches are based
on best current practices. IGMPv3 and MLDv2 snooping are also cov- on best current practices. IGMPv3 and MLDv2 snooping are also cov-
ered in this draft although we are not aware of any such implemen- ered in this draft although we are not aware of any such implemen-
tations at the time of writing. tations at the time of writing.
Note that IGMP snooping is related only to IPv4 multicast. Other Note that IGMP snooping is related only to IPv4 multicast. Other
multicast packets, such as IPv6, might be suppressed by the snoop- multicast packets, such as IPv6, might be suppressed by the snoop-
ing functionality if additional care is not taken in the implemen- ing functionality if additional care is not taken in the implemen-
tation. It is desired not to restrict the flow of non-IPv4 multi- tation. It is desired not to restrict the flow of non-IPv4 multi-
casts other than to the degree which would happen as a result of casts other than to the degree which would happen as a result of
regular bridging functions. The same note can be made of MLD snoop- regular bridging functions. The same note can be made of MLD
ing switches with respect to suppression of IPv4.
RFC DRAFT October 2002 RFC DRAFT October 2002
snooping switches with respect to suppression of IPv4.
Areas which are of relevance to IGMP and MLD snooping switches, Areas which are of relevance to IGMP and MLD snooping switches,
such as link layer topology changes and Ethernet specific encapsu- such as link layer topology changes and Ethernet specific encapsu-
lation issues, are also considered. lation issues, are also considered.
Interoperability issues that arise between different versions of Interoperability issues that arise between different versions of
IGMP are not discussed in this document. Interested readers are IGMP are not discussed in this document. Interested readers are
directed to [IGMPv3] for a thorough description of problem areas. directed to [IGMPv3] for a thorough description of problem areas.
This document is intended as an accompanying document to the IGMPv3 This document is intended as an accompanying document to the IGMPv3
and MLDv2 specifications. and MLDv2 specifications.
skipping to change at page 2, line 52 skipping to change at page 3, line 4
the upper- level protocol headers as factors to be considered in the upper- level protocol headers as factors to be considered in
the processing at the lower levels. This is analogous to the man- the processing at the lower levels. This is analogous to the man-
ner in which a router can act as a firewall by looking into the ner in which a router can act as a firewall by looking into the
transport protocol's header before allowing a packet to be for- transport protocol's header before allowing a packet to be for-
warded to its destination address. warded to its destination address.
In the case of multicast traffic, an IGMP snooping switch provides In the case of multicast traffic, an IGMP snooping switch provides
the benefit of conserving bandwidth on those segments of the net- the benefit of conserving bandwidth on those segments of the net-
work where no node has expressed interest in receiving packets work where no node has expressed interest in receiving packets
addressed to the group address. This is in contrast to normal addressed to the group address. This is in contrast to normal
switch behavior where multicast traffic is typically forwarded on
all interfaces.
RFC DRAFT October 2002 RFC DRAFT October 2002
switch behavior where multicast traffic is typically forwarded on
all interfaces.
Many switch datasheets state support for IGMP snooping, but no Many switch datasheets state support for IGMP snooping, but no
requirements for this exist today. It is the authors' hope that the requirements for this exist today. It is the authors' hope that the
information presented in this draft will supply this foundation. information presented in this draft will supply this foundation.
The requirements presented here are based on the following informa- The requirements presented here are based on the following informa-
tion sources: The IGMP specifications [RFC112][RFC2236][IGMPv3], tion sources: The IGMP specifications [RFC112][RFC2236][IGMPv3],
vendor-supplied technical documents [CISCO], bug reports [MSOFT], vendor-supplied technical documents [CISCO], bug reports [MSOFT],
discussions with people involved in the design of IGMP snooping discussions with people involved in the design of IGMP snooping
switches, MAGMA mailinglist discussions, and on replies by switch switches, MAGMA mailinglist discussions, and on replies by switch
vendors to an implementation questionnaire. vendors to an implementation questionnaire.
skipping to change at page 3, line 49 skipping to change at page 4, line 4
to those ports where multicast routers are attached. Alterna- to those ports where multicast routers are attached. Alterna-
tively stated: a snooping switch SHOULD NOT forward IGMP Mem- tively stated: a snooping switch SHOULD NOT forward IGMP Mem-
bership Reports to ports on which only hosts are attached. An bership Reports to ports on which only hosts are attached. An
administrative control MAY be provided to override this administrative control MAY be provided to override this
restriction, allowing the report messages to be flooded to restriction, allowing the report messages to be flooded to
other ports. other ports.
This is the main IGMP snooping functionality. Sending member- This is the main IGMP snooping functionality. Sending member-
ship reports (as described in IGMP versions 1 and 2) to other ship reports (as described in IGMP versions 1 and 2) to other
hosts can result in unintentionally preventing a host from hosts can result in unintentionally preventing a host from
RFC DRAFT October 2002
joining a specific multicast group. This is not a problem in joining a specific multicast group. This is not a problem in
an IGMPv3-only network because there is no cancellation of IGMP an IGMPv3-only network because there is no cancellation of IGMP
Membership reports. Membership reports.
RFC DRAFT October 2002
The administrative control allows IGMP Membership Report mes- The administrative control allows IGMP Membership Report mes-
sages to be processed by network monitoring equipment such as sages to be processed by network monitoring equipment such as
packet analyzers or port replicators. packet analyzers or port replicators.
The switch supporting IGMP snooping MUST maintain a list of The switch supporting IGMP snooping MUST maintain a list of
multicast routers and the ports on which they are attached. multicast routers and the ports on which they are attached.
This list can be constructed in any combination of the follow- This list can be constructed in any combination of the follow-
ing ways: ing ways:
a) This list SHOULD be built by the snooping switch sending a) This list SHOULD be built by the snooping switch sending
skipping to change at page 4, line 51 skipping to change at page 5, line 4
It should be noted that there may be multiple IGMP proxy- It should be noted that there may be multiple IGMP proxy-
reporting switches in the network all using the 0.0.0.0 source reporting switches in the network all using the 0.0.0.0 source
IP address. In this case the switches can be uniquely identi- IP address. In this case the switches can be uniquely identi-
fied through their link layer source MAC address. fied through their link layer source MAC address.
IGMP membership reports MUST NOT be rejected because of a IGMP membership reports MUST NOT be rejected because of a
source IP address of 0.0.0.0. source IP address of 0.0.0.0.
3) The switch that supports IGMP snooping MUST flood all unrecog- 3) The switch that supports IGMP snooping MUST flood all unrecog-
nized IGMP messages to all other ports and MUST NOT attempt to nized IGMP messages to all other ports and MUST NOT attempt to
RFC DRAFT October 2002
make use of any information beyond the end of the network layer make use of any information beyond the end of the network layer
header. header.
In addition, earlier versions of IGMP SHOULD interpret IGMP In addition, earlier versions of IGMP SHOULD interpret IGMP
RFC DRAFT October 2002
fields as defined for their versions and MUST NOT alter these fields as defined for their versions and MUST NOT alter these
fields when forwarding the message. When generating new mes- fields when forwarding the message. When generating new mes-
sages, a given IGMP version should set fields to the appropri- sages, a given IGMP version should set fields to the appropri-
ate values for its own version. If any fields are reserved or ate values for its own version. If any fields are reserved or
otherwise undefined for a given IGMP version, the fields SHOULD otherwise undefined for a given IGMP version, the fields SHOULD
be ignored when parsing the message and MUST be set to zeroes be ignored when parsing the message and MUST be set to zeroes
when new messages are generated by implementations of that IGMP when new messages are generated by implementations of that IGMP
version. version.
4) An IGMP snooping switch SHOULD be aware of link layer topology 4) An IGMP snooping switch SHOULD be aware of link layer topology
skipping to change at page 5, line 49 skipping to change at page 6, line 4
2.1.2. Data Forwarding Rules 2.1.2. Data Forwarding Rules
1) Packets with a destination IP (DIP) address in the 224.0.0.X 1) Packets with a destination IP (DIP) address in the 224.0.0.X
range which are not IGMP MUST be forwarded on all ports. range which are not IGMP MUST be forwarded on all ports.
This requirement is based on fact that many hosts exist today This requirement is based on fact that many hosts exist today
which do not Join IP multicast addresses in this range before which do not Join IP multicast addresses in this range before
sending or listening to IP multicasts. Furthermore since the sending or listening to IP multicasts. Furthermore since the
224.0.0.X address range is defined as link local (not to be 224.0.0.X address range is defined as link local (not to be
routed) it seems unnecessary to keep state for each address in routed) it seems unnecessary to keep state for each address in
RFC DRAFT October 2002
this range. Additionally, some vendors' applications, which this range. Additionally, some vendors' applications, which
are not IGMP, use this 224.0.0.X address range, and these are not IGMP, use this 224.0.0.X address range, and these
applications would break if the switch were to prune them due applications would break if the switch were to prune them due
to not seeing a Join. to not seeing a Join.
RFC DRAFT October 2002
2) Packets with a destination IP address outside 224.0.0.X which 2) Packets with a destination IP address outside 224.0.0.X which
are not IGMP SHOULD be forwarded according to group-based port are not IGMP SHOULD be forwarded according to group-based port
membership tables and MUST also be forwarded on router ports. membership tables and MUST also be forwarded on router ports.
This is the core IGMP snooping requirement for the data path. This is the core IGMP snooping requirement for the data path.
Discussion: An implementation could maintain separate member- Discussion: An implementation could maintain separate member-
ship and multicast router tables in software and then "merge" ship and multicast router tables in software and then "merge"
these tables into a current forwarding cache. these tables into a current forwarding cache.
skipping to change at page 6, line 50 skipping to change at page 7, line 4
both types of forwarding tables then the default behavior both types of forwarding tables then the default behavior
SHOULD be to use IP addresses. SHOULD be to use IP addresses.
Discussion: Forwarding based on MAC addresses is subject to the Discussion: Forwarding based on MAC addresses is subject to the
problem associated with the 32-fold IP address to 1 MAC address problem associated with the 32-fold IP address to 1 MAC address
mapping. mapping.
6) Switches which rely on information in the IP header SHOULD ver- 6) Switches which rely on information in the IP header SHOULD ver-
ify that the IP header checksum is correct. If the checksum ify that the IP header checksum is correct. If the checksum
fails, the information in the packet MUST NOT be incorporated fails, the information in the packet MUST NOT be incorporated
RFC DRAFT October 2002
into the forwarding table. Further, the packet SHOULD be dis- into the forwarding table. Further, the packet SHOULD be dis-
carded. carded.
7) The "include source" and "exclude source" options in IGMPv3 do 7) The "include source" and "exclude source" options in IGMPv3 do
not work on shared segments. These options are used to register not work on shared segments. These options are used to register
RFC DRAFT October 2002
for multicast traffic only from certain senders, or from all for multicast traffic only from certain senders, or from all
except certain senders. On shared segments, if one host has except certain senders. On shared segments, if one host has
registered to receive a multicast data stream but has used the registered to receive a multicast data stream but has used the
"include source" or "exclude source" option, any additional "include source" or "exclude source" option, any additional
hosts that later request membership for that same multicast hosts that later request membership for that same multicast
group must accept the restrictions issued in the first host's group must accept the restrictions issued in the first host's
request. request.
2.2. IGMP snooping related problems 2.2. IGMP snooping related problems
skipping to change at page 7, line 38 skipping to change at page 7, line 43
Therefore it is recommended that in such a network, the multicast Therefore it is recommended that in such a network, the multicast
router be configured to use IGMPv2. router be configured to use IGMPv2.
3. IPv6 Considerations 3. IPv6 Considerations
In order to avoid confusion, the previous discussions have been In order to avoid confusion, the previous discussions have been
based on the IGMP protocol which only applies to IPv4 multicast. based on the IGMP protocol which only applies to IPv4 multicast.
In the case of IPv6 most of the above discussions are still valid In the case of IPv6 most of the above discussions are still valid
with a few exceptions which we will describe here. with a few exceptions which we will describe here.
The control and data forwarding rules in the IGMP section can with The control and data forwarding rules in the IGMP section can, with
a few considerations also be applied to MLD. This means that the a few considerations, also be applied to MLD. This means that the
basic functionality of intercepting MLD packets, building member- basic functionality of intercepting MLD packets, and building mem-
ship lists and multicast router lists is the same as for IGMP. bership lists and multicast router lists, is the same as for IGMP.
In IPv6, the data forwarding rules are more straight forward In IPv6, the data forwarding rules are more straight forward
because MLD is mandated for addresses with scope 2 (link-scope) or because MLD is mandated for addresses with scope 2 (link-scope) or
greater. The only exception is the address FF002::1 which is the greater. The only exception is the address FF002::1 which is the
all hosts link-scope address for which MLD messages are never sent. all hosts link-scope address for which MLD messages are never sent.
Packets with the all hosts link-scope address should be forwarded Packets with the all hosts link-scope address should be forwarded
on all ports.
MLD messages are also not sent to packets in the address range
FF00X::/16 when X is 0 or 1 which are reserved and node-local
respectively, and these addresses should never appear in packets on
RFC DRAFT October 2002 RFC DRAFT October 2002
the link. on all ports.
MLD messages are also not sent to packets in the address range
FF00X::/16 when X is 0 or 1 (which are reserved and node-local,
respectively), and these addresses should never appear in packets
on the link.
The three main differences between IPv4 and IPv6 in relation to The three main differences between IPv4 and IPv6 in relation to
multicast are: multicast are:
- The IPv6 protocol for multicast group maintenance is called Mul- - The IPv6 protocol for multicast group maintenance is called Mul-
ticast Listener Discovery (MLDv2). MLDv2 uses ICMPv6 message ticast Listener Discovery (MLDv2). MLDv2 uses ICMPv6 message
types instead of IGMP message types. types instead of IGMP message types.
- The ethernet encapsulation is a mapping of 32 bits of the 128 - The ethernet encapsulation is a mapping of 32 bits of the 128
bit DIP addresses into 48 bit DMAC addresses [IPENCAPS]. bit DIP addresses into 48 bit DMAC addresses [IPENCAPS].
skipping to change at page 8, line 35 skipping to change at page 8, line 40
information from the corresponding packet in the MLD forwarding ta- information from the corresponding packet in the MLD forwarding ta-
ble. The forwarding code SHOULD drop the packet and take further ble. The forwarding code SHOULD drop the packet and take further
reasonable actions as advocated above. reasonable actions as advocated above.
The fact that MLDv2 is using ICMPv6 adds new requirements to a The fact that MLDv2 is using ICMPv6 adds new requirements to a
snooping switch because ICMPv6 has multiple uses aside from MLD. snooping switch because ICMPv6 has multiple uses aside from MLD.
This means that it is no longer sufficient to detect that the next- This means that it is no longer sufficient to detect that the next-
header field of the IP header is ICMPv6 in order to identify pack- header field of the IP header is ICMPv6 in order to identify pack-
ets relevant for MLD snooping. ets relevant for MLD snooping.
Discussion: If an implementation was software based, wrongly iden- Discussion: If an implementation was software-based, wrongly iden-
tifying non-MLD packets as candidates for MLD snooping, would tifying non-MLD packets as candidates for MLD snooping would poten-
potentially fill the CPU queue with irellevant packets thus pre- tially fill the CPU queue with irrelevant packets thus preventing
venting the snooping functionality. Furthermore, ICMPv6 packets the snooping functionality. Furthermore, ICMPv6 packets destined
destined for other hosts would not reach their destinations. for other hosts would not reach their destinations.
A solution is either to require that the snooping switch looks fur- A solution is either to require that the snooping switch looks fur-
ther into the packets, or to be able to detect a multicast DMAC ther into the packets, or to be able to detect a multicast DMAC
address in conjunction with ICMPv6. The first solution is desir- address in conjunction with ICMPv6. The first solution is desir-
able only if it is configurable which message types should trigger able only if it is configurable which message types should trigger
a CPU redirect and which should not. The reason is that a hardcod- a CPU redirect and which should not. The reason is that a hardcod-
ing of message types is unflexible for the introduction of new mes- ing of message types is inflexible for the introduction of new mes-
sage types. The second solution introduces the risk of new proto- sage types. The second solution introduces the risk of new proto-
cols, which are not related to MLD but use ICMPv6 and multicast cols which use ICMPv6 and multicast DMAC addresses but which are
DMAC addresses, wrongly being identified as MLD. It is suggested not related to MLD, wrongly being identified as MLD. It is
that solution one is the preferred if the switch is capable of
triggering CPU redirects on individual ICMPv6 message types. If
this is not the case, then use solution two.
The mapping from IP multicast addresses to multicast DMAC addresses
RFC DRAFT October 2002 RFC DRAFT October 2002
suggested that solution one is preferred if the switch is capable
of triggering CPU redirects on individual ICMPv6 message types. If
this is not the case, then use solution two.
The mapping from IP multicast addresses to multicast DMAC addresses
introduces a potentially enormous overlap. The structure of an IPv6 introduces a potentially enormous overlap. The structure of an IPv6
multicast address is shown in the figure below. Theoretically multicast address is shown in the figure below. Theoretically
2**80, two to the power of 80 (128 - 8 - 4 - 4 - 32) unique DIP 2**80, two to the power of 80 (128 - 8 - 4 - 4 - 32) unique DIP
addresses could map to one DMAC address. This should be compared to addresses could map to one DMAC address. This should be compared to
2**5 in the case of IPv4. 2**5 in the case of IPv4.
Initial allocation of IPv6 multicast addresses, however, uses only Initial allocation of IPv6 multicast addresses, however, uses only
the lower 32 bits of group ID. This eliminates the address ambigu- the lower 32 bits of group ID. This eliminates the address ambigu-
ity for the time being, but it should be noted that the allocation ity for the time being, but it should be noted that the allocation
policy may change in the future. Because of the potential overlap policy may change in the future. Because of the potential overlap
skipping to change at page 9, line 31 skipping to change at page 9, line 36
+--------+----+----+---------------------------------------+ +--------+----+----+---------------------------------------+
|11111111|flgs|scop| group ID | |11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------+ +--------+----+----+---------------------------------------+
4. Security Considerations 4. Security Considerations
Security considerations for IGMPv3 are accounted for in [IGMPv3]. Security considerations for IGMPv3 are accounted for in [IGMPv3].
The introduction of IGMP snooping switches adds the following con- The introduction of IGMP snooping switches adds the following con-
siderations with regard to IP multicast. siderations with regard to IP multicast.
The exclude source failure which could cause traffic from sources 1) The exclude source failure, which could cause traffic from
that are 'black listed' to reach hosts that have requested other- sources that are 'black listed' to reach hosts that have requested
wise. This can also occur in certain network topologies without otherwise. This can also occur in certain network topologies with-
IGMP snooping. out IGMP snooping.
It is possible to generate packets which make the switch wrongly 2) It is possible to generate packets which make the switch wrongly
believe that there is a multicast router on the segment on which believe that there is a multicast router on the segment on which
the source is attached. This will potentially lead to excessive the source is attached. This will potentially lead to excessive
flooding on that segment. The authentication methods discussed in flooding on that segment. The authentication methods discussed in
[IGMPv3] will also provide protection in this case. [IGMPv3] will also provide protection in this case.
IGMP snooping switches which rely on the IP header of a packet for 3) IGMP snooping switches which rely on the IP header of a packet
their operation and which do not validate the header checksum for their operation and which do not validate the header checksum
potentially will forward packets on the wrong ports. Even though potentially will forward packets on the wrong ports. Even though
the IP headers are protected by the ethernet checksum this is a the IP headers are protected by the ethernet checksum this is a
potential vulnerability. potential vulnerability.
RFC DRAFT October 2002
Generally though, it is worth it to stress that IP multicast must Generally though, it is worth it to stress that IP multicast must
so far be considered insecure until the work of for example the so far be considered insecure until the work of for example the
suggested Multicast Security (MSEC) working group or similar is suggested Multicast Security (MSEC) working group or similar is
completed or at least has matured. completed or at least has matured.
RFC DRAFT October 2002
5. IGMP Questionnaire 5. IGMP Questionnaire
As part of this work the following questions were asked both on the As part of this work the following questions were asked both on the
MAGMA discussion list and sent to known switch vendors implementing MAGMA discussion list and sent to known switch vendors implementing
IGMP snooping. The individual contributions have been anonymized IGMP snooping. The individual contributions have been anonymized
upon request and do not necessarily apply to all of the vendors' upon request and do not necessarily apply to all of the vendors'
products. products.
The questions were: The questions were:
skipping to change at page 10, line 49 skipping to change at page 11, line 5
Q6 Does your switch support forwarding to ports on which IP multi- Q6 Does your switch support forwarding to ports on which IP multi-
cast routers are attached in addition to the ports where IGMP cast routers are attached in addition to the ports where IGMP
Joins have been received? Joins have been received?
Q7 Is your IGMP snooping functionality fully implemented in hard- Q7 Is your IGMP snooping functionality fully implemented in hard-
ware? ware?
Q8 Is your IGMP snooping functionality partly software imple- Q8 Is your IGMP snooping functionality partly software imple-
mented? mented?
RFC DRAFT October 2002
Q9 Can topology changes (for example spanning tree configuration Q9 Can topology changes (for example spanning tree configuration
changes) be detected by the IGMP snooping functionality so that changes) be detected by the IGMP snooping functionality so that
for example new queries can be sent or tables can be updated to for example new queries can be sent or tables can be updated to
ensure robustness? ensure robustness?
RFC DRAFT October 2002
The answers were: The answers were:
---------------------------+-----------------------+ ---------------------------+-----------------------+
| Switch Vendor | | Switch Vendor |
---------------------------+---+---+---+---+---+---+ ---------------------------+---+---+---+---+---+---+
| 1 | 2 | 3 | 4 | 5 | 6 | | 1 | 2 | 3 | 4 | 5 | 6 |
---------------------------+---+---+---+---+---+---+ ---------------------------+---+---+---+---+---+---+
Q1 Join aggregation | x | x | x | | x | x | Q1 Join aggregation | x | x | x | | x | x |
Q2 Layer-2 forwarding | x | x | x | x |(1)| | Q2 Layer-2 forwarding | x | x | x | x |(1)| |
Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x | Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x |
skipping to change at page 11, line 44 skipping to change at page 12, line 5
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such pro- to obtain a general license or permission for the use of such pro-
prietary rights by implementors or users of this specification can prietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat." be obtained from the IETF Secretariat."
RFC DRAFT October 2002
7. References 7. References
[BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges"
[CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP [CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP
and IGMP snooping", and IGMP snooping", http://www.cisco.com/warp/pub-
lic/473/22.html
RFC DRAFT October 2002
http://www.cisco.com/warp/public/473/22.html
[IANA] Internet Assigned Numbers Authority, "Internet Multicast [IANA] Internet Assigned Numbers Authority, "Internet Multicast
Addresses", http://www.isi.edu/in-notes/iana/assign- Addresses", http://www.isi.edu/in-notes/iana/assign-
ments/multicast-addresses ments/multicast-addresses
[IGMPv3] Cain, B., "Internet Group Management Protocol, Version [IGMPv3] Cain, B., "Internet Group Management Protocol, Version
3", draft-ietf-idmr-igmp-v3-11.txt, May 2002. 3", draft-ietf-idmr-igmp-v3-11.txt, May 2002.
[IPENCAPS] Crawford, M., "Transmission of IPv6 Packets over Ether- [IPENCAPS] Crawford, M., "Transmission of IPv6 Packets over Ether-
net Networks", RFC2464, December 1998. net Networks", RFC2464, December 1998.
skipping to change at page 12, line 47 skipping to change at page 13, line 5
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC
1112, August 1989. 1112, August 1989.
[RFC2026] Bradner, S. "The Internet Standards Process -- Revision [RFC2026] Bradner, S. "The Internet Standards Process -- Revision
3", RFC2026, October 1996. 3", RFC2026, October 1996.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC2236, November 1997. 2", RFC2236, November 1997.
RFC DRAFT October 2002
[RFC2375] Hinden, R. "IPv6 Multicast Address Assignments", [RFC2375] Hinden, R. "IPv6 Multicast Address Assignments",
RFC2375, July 1998. RFC2375, July 1998.
8. Acknowledgements 8. Acknowledgements
We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter, We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter,
Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward
RFC DRAFT October 2002
Hilquist, Hugh Holbrook, Kevin Humphries, Suzuki Shinsuke, Jaff Hilquist, Hugh Holbrook, Kevin Humphries, Suzuki Shinsuke, Jaff
Thomas and Rolland Vida for comments and suggestions on this docu- Thomas and Rolland Vida for comments and suggestions on this docu-
ment. ment.
Furthermore, the following companies are acknowledged for their Furthermore, the following companies are acknowledged for their
contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks, contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks,
Hewlett-Packard, Vitesse Semiconductor Corporation. The ordering Hewlett-Packard, Vitesse Semiconductor Corporation. The ordering
of these names do not necessarily correspond to the column numbers of these names do not necessarily correspond to the column numbers
in the response table. in the response table.
9. Revision History 9. Revision History
This section, while incomplete, is provided as a convenience to the This section, while incomplete, is provided as a convenience to the
working group members. It will be removed when the document is working group members. It will be removed when the document is
released in its final form. released in its final form.
draft-ietf-magma-snoop-04.txt: November 2002 Editorial changes
only.
draft-ietf-magma-snoop-03.txt: October 2002 draft-ietf-magma-snoop-03.txt: October 2002
IGMP Forwarding rules: IGMP Forwarding rules:
Add references to and become consistant with the current IGMP Add references to and become consistant with the current IGMP
proxy draft, proxy draft,
Unrecognized IGMP packets should not be ignored because "mbz" Unrecognized IGMP packets should not be ignored because "mbz"
fields are not zero since packets from future versions are fields are not zero since packets from future versions are
expected to maintain consistency. expected to maintain consistency.
Corrections related to IGMP Querier election process. Corrections related to IGMP Querier election process.
Include discussion about aging out entries from the internal
forwarding table.
Add clarification to how lists of router ports may be assem- Add clarification to how lists of router ports may be assem-
bled. bled.
Data Forwarding rules: Data Forwarding rules:
Added discussion of the problems for different IGMP environ- Added discussion of the problems for different IGMP environ-
ments in choosing whether to flood or to prune unregistered ments in choosing whether to flood or to prune unregistered
multicasts. multicasts.
RFC DRAFT October 2002
Added refinements for how to handle NON-IPv4 multicasts, to Added refinements for how to handle NON-IPv4 multicasts, to
keep IGMP-snooping functionality from interfering with IPv6 keep IGMP-snooping functionality from interfering with IPv6
and other multicast traffic. Any filtering for non-IPv4 multi- and other multicast traffic. Any filtering for non-IPv4 multi-
casts should be based on bridge behavior and not IGMP snooping casts should be based on bridge behavior and not IGMP snooping
behavior. behavior.
IGMP snooping related problems: IGMP snooping related problems:
RFC DRAFT October 2002
Fixed description of interoperability issues in environments Fixed description of interoperability issues in environments
with v3 routers and hosts, and v2 snooping switches. with v3 routers and hosts, and v2 snooping switches.
Added discussion of the IGMPv3 "include source" and "exclude Added discussion of the IGMPv3 "include source" and "exclude
source" options, and the inability to support them on shared source" options, and the inability to support them on shared
segments. segments.
IPv6 Considerations: IPv6 Considerations:
Clarifications regarding address ranges FF00::, FF01:: and all Clarifications regarding address ranges FF00::, FF01:: and all
hosts FF02::1 in relation to data forwarding. hosts FF02::1 in relation to data forwarding.
skipping to change at page 14, line 47 skipping to change at page 15, line 5
"SHOULD use network addresses". "SHOULD use network addresses".
Added two sets of additional responses to the questionnaire Added two sets of additional responses to the questionnaire
and text indicating that responses don't cover all products. and text indicating that responses don't cover all products.
Removed (commented out) description of IPR issues: IESG is Removed (commented out) description of IPR issues: IESG is
aware of them. aware of them.
draft-ietf-magma-snoop-01.txt: January 2002 draft-ietf-magma-snoop-01.txt: January 2002
RFC DRAFT October 2002
Extensive restructuring of the original text. Extensive restructuring of the original text.
draft-ietf-idmr-snoop-01.txt: 2001 draft-ietf-idmr-snoop-01.txt: 2001
Added several descriptions of cases where IGMP snooping imple- Added several descriptions of cases where IGMP snooping imple-
mentations face problems. Also added several network topology mentations face problems. Also added several network topology
RFC DRAFT October 2002
figures. figures.
draft-ietf-idmr-snoop-00.txt: 2001 draft-ietf-idmr-snoop-00.txt: 2001
Initial snooping draft. An overview of IGMP snooping and the Initial snooping draft. An overview of IGMP snooping and the
problems to be solved. problems to be solved.
10. Author's Addresses 10. Author's Addresses
Morten Jagd Christensen Morten Jagd Christensen
jCAPS jCAPS
Begoniavej 13
2820 Gentofte
email: mjc@jcaps.com email: mjc@jcaps.com
Karen Kimball Karen Kimball
Hewlett-Packard Hewlett-Packard
8000 Foothills Blvd.
Roseville, CA 95747
email: karen.kimball@hp.com email: karen.kimball@hp.com
Frank Solensky Frank Solensky
email: solenskyf@acm.org Bluejavelin, Inc.
3 Dundee Park
Andover, MA 01810
email: fsolensky@bluejavelin.net
RFC DRAFT October 2002 RFC DRAFT October 2002
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . 2
2. IGMP Snooping Requirements . . . . . . . . . . . . . . 3 2. IGMP Snooping Requirements . . . . . . . . . . . . . . 3
2.1. Forwarding rules . . . . . . . . . . . . . . . . . . 3 2.1. Forwarding rules . . . . . . . . . . . . . . . . . . 3
2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . 3 2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . 3
2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . 5 2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . 5
2.2. IGMP snooping related problems . . . . . . . . . . . 7 2.2. IGMP snooping related problems . . . . . . . . . . . 7
3. IPv6 Considerations . . . . . . . . . . . . . . . . . . 7 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . 9
5. IGMP Questionnaire . . . . . . . . . . . . . . . . . . 10 5. IGMP Questionnaire . . . . . . . . . . . . . . . . . . 10
6. IETF IPR Statement . . . . . . . . . . . . . . . . . . 11 6. IETF IPR Statement . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . 13
9. Revision History . . . . . . . . . . . . . . . . . . . 13 9. Revision History . . . . . . . . . . . . . . . . . . . 13
10. Author's Addresses . . . . . . . . . . . . . . . . . . 15 10. Author's Addresses . . . . . . . . . . . . . . . . . . 15
 End of changes. 42 change blocks. 
71 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/