< draft-ietf-magma-snoop-11.txt   draft-ietf-magma-snoop-12.txt >
Network Working Group M. Christensen Network Working Group M. Christensen
Internet Draft Thrane & Thrane Internet Draft Thrane & Thrane
Expiration Date: November 2004 K. Kimball Expiration Date: August 2005 K. Kimball
Category: Informational Hewlett-Packard Category: Informational Hewlett-Packard
F. Solensky F. Solensky
West Ridge Networks Calix Networks
May 2004 February 2005
Considerations for IGMP and MLD Snooping Switches Considerations for IGMP and MLD Snooping Switches
<draft-ietf-magma-snoop-11.txt> <draft-ietf-magma-snoop-12.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 36 skipping to change at page 1, line 36
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been
disclosed, or will be disclosed, and any of which we become aware
will be disclosed, in accordance with RFC 3668 [IPR].
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All rights reserved.
Abstract Abstract
This memo describes the recommendations for IGMP- and MLD-snooping This memo describes the recommendations for IGMP- and MLD-snooping
switches. These are based on best current practices for IGMPv2, switches. These are based on best current practices for IGMPv2,
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
with further considerations for IGMPv3- and MLDv2-snooping. with further considerations for IGMPv3- and MLDv2-snooping.
Additional areas of relevance, such as link layer topology changes Additional areas of relevance, such as link layer topology changes
and Ethernet-specific encapsulation issues, are also considered. and Ethernet-specific encapsulation issues, are also considered.
MLD Snooping Switches
1. Introduction 1. Introduction
The IEEE bridge standard [BRIDGE] specifies how LAN packets are The IEEE bridge standard [BRIDGE] specifies how LAN packets are
'bridged', or as is more commonly used today, switched between LAN 'bridged', or as is more commonly used today, switched between LAN
segments. The operation of a switch with respect to multicast segments. The operation of a switch with respect to multicast
packets can be summarized as follows. When processing a packet packets can be summarized as follows. When processing a packet
whose destination MAC address is a multicast address, the switch whose destination MAC address is a multicast address, the switch
will forward a copy of the packet into each of the remaining will forward a copy of the packet into each of the remaining
network interfaces that are in the forwarding state in accordance network interfaces that are in the forwarding state in accordance
with [BRIDGE]. The spanning tree algorithm ensures that the with [BRIDGE]. The spanning tree algorithm ensures that the
skipping to change at page 1, line 93 skipping to change at page 1, line 100
the transport protocol's header before allowing a packet to be the transport protocol's header before allowing a packet to be
forwarded to its destination address. forwarded to its destination address.
In the case of IP multicast traffic, an IGMP snooping switch In the case of IP multicast traffic, an IGMP snooping switch
provides the benefit of conserving bandwidth on those segments of provides the benefit of conserving bandwidth on those segments of
the network where no node has expressed interest in receiving the network where no node has expressed interest in receiving
packets addressed to the group address. This is in contrast to packets addressed to the group address. This is in contrast to
normal switch behavior where multicast traffic is typically normal switch behavior where multicast traffic is typically
forwarded on all interfaces. forwarded on all interfaces.
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
Many switch datasheets state support for IGMP snooping, but no Many switch datasheets state support for IGMP snooping, but no
recommendations for this exist today. It is the authors' hope that recommendations for this exist today. It is the authors' hope that
the information presented in this draft will supply this the information presented in this draft will supply this
foundation. foundation.
MLD Snooping Switches
The recommendations presented here are based on the following The recommendations presented here are based on the following
information sources: The IGMP specifications [RFC1112], [RFC2236] information sources: The IGMP specifications [RFC1112], [RFC2236]
and [IGMPv3], vendor-supplied technical documents [CISCO], bug and [IGMPv3], vendor-supplied technical documents [CISCO], bug
reports [MSOFT], discussions with people involved in the design of reports [MSOFT], discussions with people involved in the design of
IGMP snooping switches, MAGMA mailing list discussions, and on IGMP snooping switches, MAGMA mailing list discussions, and on
replies by switch vendors to an implementation questionnaire. replies by switch vendors to an implementation questionnaire.
Interoperability issues that arise between different versions of Interoperability issues that arise between different versions of
IGMP are not the focus of this document. Interested readers are IGMP are not the focus of 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.
skipping to change at page 1, line 141 skipping to change at page 1, line 149
snooping switch. The recommendation is stated and is supplemented snooping switch. The recommendation is stated and is supplemented
by a description of a possible implementation approach. All by a description of a possible implementation approach. All
implementation discussions are examples only and there may well be implementation discussions are examples only and there may well be
other ways to achieve the same functionality. other ways to achieve the same functionality.
2.1. Forwarding rules 2.1. Forwarding rules
The IGMP snooping functionality is separated into a control section The IGMP snooping functionality is separated into a control section
(IGMP forwarding) and a data section (Data forwarding). (IGMP forwarding) and a data section (Data forwarding).
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
2.1.1. IGMP Forwarding Rules 2.1.1. IGMP Forwarding Rules
1) A snooping switch should forward IGMP Membership Reports only 1) A snooping switch should forward IGMP Membership Reports only
to those ports where multicast routers are attached. to those ports where multicast routers are attached.
MLD Snooping Switches
Alternatively stated: a snooping switch should not forward IGMP Alternatively stated: a snooping switch should not forward IGMP
Membership Reports to ports on which only hosts are attached. Membership Reports to ports on which only hosts are attached.
An administrative control may be provided to override this An 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 for the control This is the main IGMP snooping functionality for the control
path. path.
Sending membership reports to other hosts can result, for Sending membership reports to other hosts can result, for
skipping to change at page 1, line 192 skipping to change at page 1, line 200
Multicast Router Solicitation messages as described in IGMP Multicast Router Solicitation messages as described in IGMP
Multicast Router Discovery [MRDISC]. It may also snoop Multicast Router Discovery [MRDISC]. It may also snoop
Multicast Router Advertisement messages sent by and to Multicast Router Advertisement messages sent by and to
other nodes. other nodes.
b) The arrival port for IGMP Queries (sent by multicast b) The arrival port for IGMP Queries (sent by multicast
routers) where the source address is not 0.0.0.0. routers) where the source address is not 0.0.0.0.
The 0.0.0.0 address represents a special case where the The 0.0.0.0 address represents a special case where the
switch is proxying IGMP Queries for faster network switch is proxying IGMP Queries for faster network
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
convergence, but is not itself the Querier. The switch convergence, but is not itself the Querier. The switch
does not use its own IP address (even if it has one), does not use its own IP address (even if it has one),
because this would cause the Queries to be seen as coming because this would cause the Queries to be seen as coming
from a newly elected Querier. The 0.0.0.0 address is used from a newly elected Querier. The 0.0.0.0 address is used
MLD Snooping Switches
to indicate that the Query packets are NOT from a multicast to indicate that the Query packets are NOT from a multicast
router. router.
c) Ports explicitly configured by management to be IGMP- c) Ports explicitly configured by management to be IGMP-
forwarding ports, in addition to or instead of any of the forwarding ports, in addition to or instead of any of the
above methods to detect router ports. above methods to detect router ports.
2) IGMP networks may include devices which implement "proxy- 2) IGMP networks may include devices which implement "proxy-
reporting", in which reports received from downstream hosts are reporting", in which reports received from downstream hosts are
summarized and used to build internal membership states. Such summarized and used to build internal membership states. Such
skipping to change at page 1, line 241 skipping to change at page 1, line 251
The reason to worry about these trivialities is that IGMPv3 The reason to worry about these trivialities is that IGMPv3
overloads the old IGMP query message using the same type number overloads the old IGMP query message using the same type number
(0x11) but with an extended header. Therefore there is a risk (0x11) but with an extended header. Therefore there is a risk
that IGMPv3 queries may be interpreted as older version queries that IGMPv3 queries may be interpreted as older version queries
by, for example, IGMPv2 snooping switches. This has already by, for example, IGMPv2 snooping switches. This has already
been reported [IETF56] and is discussed in section 2.2. been reported [IETF56] and is discussed in section 2.2.
4) An IGMP snooping switch should be aware of link layer topology 4) An IGMP snooping switch should be aware of link layer topology
changes caused by Spanning Tree operation. When a port is changes caused by Spanning Tree operation. When a port is
enabled or disabled by Spanning Tree, a General Query may be enabled or disabled by Spanning Tree, a General Query may be
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
sent on all active non-router ports in order to reduce network sent on all active non-router ports in order to reduce network
convergence time. Non-Querier switches should be aware of convergence time. Non-Querier switches should be aware of
whether the Querier is in IGMPv3 mode. If so, the switch should whether the Querier is in IGMPv3 mode. If so, the switch should
not spoof any General Queries unless it is able to send an not spoof any General Queries unless it is able to send an
MLD Snooping Switches
IGMPv3 Query that adheres to the most recent information sent IGMPv3 Query that adheres to the most recent information sent
by the true Querier. In no case should a switch introduce a by the true Querier. In no case should a switch introduce a
spoofed IGMPv2 Query into an IGMPv3 network, as this may create spoofed IGMPv2 Query into an IGMPv3 network, as this may create
excessive network disruption. excessive network disruption.
If the switch is not the Querier, it should use the 'all-zeros' If the switch is not the Querier, it should use the 'all-zeros'
IP Source Address in these proxy queries (even though some IP Source Address in these proxy queries (even though some
hosts may elect to not process queries with a 0.0.0.0 IP Source hosts may elect to not process queries with a 0.0.0.0 IP Source
Address). When such proxy queries are received, they must not Address). When such proxy queries are received, they must not
be included in the Querier election process. be included in the Querier election process.
skipping to change at page 1, line 290 skipping to change at page 1, line 302
This is the main IGMP snooping functionality for the data path. This is the main IGMP snooping functionality for the data path.
One approach that an implementation could take would be to One approach that an implementation could take would be to
maintain separate membership and multicast router tables in maintain separate membership and multicast router tables in
software and then "merge" these tables into a forwarding cache. software and then "merge" these tables into a forwarding cache.
2) Packets with a destination IP (DIP) address in the 224.0.0.X 2) 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 recommendation is based on fact that many host systems do This recommendation is based on fact that many host systems do
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
not send Join IP multicast addresses in this range before not send Join IP multicast addresses in this range before
sending or listening to IP multicast packets. Furthermore, sending or listening to IP multicast packets. Furthermore,
since the 224.0.0.X address range is defined as link-local (not since the 224.0.0.X address range is defined as link-local (not
to be routed) it seems unnecessary to keep state for each to be routed) it seems unnecessary to keep state for each
MLD Snooping Switches
address in this range. Additionally, some routers operate in address in this range. Additionally, some routers operate in
the 224.0.0.X address range without issuing IGMP Joins, and the 224.0.0.X address range without issuing IGMP Joins, and
these applications would break if the switch were to prune them these applications would break if the switch were to prune them
due to not having seen a Join Group message from the router. due to not having seen a Join Group message from the router.
3) An unregistered packet is defined as an IPv4 multicast packet 3) An unregistered packet is defined as an IPv4 multicast packet
with a destination address which does not match any of the with a destination address which does not match any of the
groups announced in earlier IGMP Membership Reports. groups announced in earlier IGMP Membership Reports.
If a switch receives an unregistered packet, it must forward If a switch receives an unregistered packet, it must forward
skipping to change at page 1, line 340 skipping to change at page 1, line 354
previously been joined as IGMPv2 (because the data stream is previously been joined as IGMPv2 (because the data stream is
seen as already having been registered). seen as already having been registered).
4) All non-IPv4 multicast packets should continue to be flooded 4) All non-IPv4 multicast packets should continue to be flooded
out all remaining ports in the forwarding state as per normal out all remaining ports in the forwarding state as per normal
IEEE bridging operations. IEEE bridging operations.
This recommendation is a result of the fact that groups made up This recommendation is a result of the fact that groups made up
of IPv4 hosts and IPv6 hosts are completely separate and of IPv4 hosts and IPv6 hosts are completely separate and
distinct groups. As a result, information gleaned from the distinct groups. As a result, information gleaned from the
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
topology between members of an IPv4 group would not be topology between members of an IPv4 group would not be
applicable when forming the topology between members of an IPv6 applicable when forming the topology between members of an IPv6
group. group.
MLD Snooping Switches
5) IGMP snooping switches may maintain forwarding tables based on 5) IGMP snooping switches may maintain forwarding tables based on
either MAC addresses or IP addresses. If a switch supports either MAC addresses or IP addresses. If a switch supports
both types of forwarding tables then the default behavior both types of forwarding tables then the default behavior
should be to use IP addresses. IP address based forwarding is should be to use IP addresses. IP address based forwarding is
preferred because the mapping between IP multicast addresses preferred because the mapping between IP multicast addresses
and link-layer multicast addresses is ambiguous. In the case and link-layer multicast addresses is ambiguous. In the case
of Ethernet, there is a multiplicity of 1 Ethernet address to of Ethernet, there is a multiplicity of 1 Ethernet address to
32 IP addresses [RFC1112]. 32 IP addresses [RFC1112].
6) Switches which rely on information in the IP header should 6) Switches which rely on information in the IP header should
skipping to change at page 1, line 388 skipping to change at page 1, line 404
2.2. IGMP snooping-related problems 2.2. IGMP snooping-related problems
A special problem arises in networks consisting of IGMPv3 routers A special problem arises in networks consisting of IGMPv3 routers
as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2
snooping switch as recently reported [IETF56]. The router will snooping switch as recently reported [IETF56]. The router will
continue to maintain IGMPv3 even in the presence of IGMPv2 hosts, continue to maintain IGMPv3 even in the presence of IGMPv2 hosts,
and thus the network will not converge on IGMPv2. But it is likely and thus the network will not converge on IGMPv2. But it is likely
that the IGMPv2 snooping switch will not recognize or process the that the IGMPv2 snooping switch will not recognize or process the
IGMPv3 membership reports. Groups for these unrecognized reports IGMPv3 membership reports. Groups for these unrecognized reports
will then either be flooded (with all of the problems that may will then either be flooded (with all of the problems that may
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
create for hosts in a network with a heavy multicast load) or create for hosts in a network with a heavy multicast load) or
pruned by the snooping switch. pruned by the snooping switch.
Therefore, it is recommended that in such a network, the multicast Therefore, it is recommended that in such a network, the multicast
MLD Snooping Switches
router be configured to use IGMPv2. If this is not possible, and if router be configured to use IGMPv2. If this is not possible, and if
the snooping switch cannot recognize and process the IGMPv3 the snooping switch cannot recognize and process the IGMPv3
membership reports, it is instead recommended that the switch's membership reports, it is instead recommended that the switch's
IGMP snooping functionality be disabled, as there is no clear IGMP snooping functionality be disabled, as there is no clear
solution to this problem. solution to this problem.
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.
skipping to change at page 1, line 437 skipping to change at page 1, line 455
snooping switch because of an unspecified IP source address (::). snooping switch because of an unspecified IP source address (::).
Additionally, if a non-Querier switch spoofs any General Queries Additionally, if a non-Querier switch spoofs any General Queries
(as addressed in Section 2.1 above, for Spanning Tree topology (as addressed in Section 2.1 above, for Spanning Tree topology
changes), the switch should use the null IP source address (::) changes), the switch should use the null IP source address (::)
when sending said queries. When such proxy queries are received, when sending said queries. When such proxy queries are received,
they must not be included in the Querier election process. they must not be included in the Querier election process.
The three major differences between IPv4 and IPv6 in relation to The three major differences between IPv4 and IPv6 in relation to
multicast are: multicast are:
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
- The IPv6 protocol for multicast group maintenance is called - The IPv6 protocol for multicast group maintenance is called
Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message
types instead of IGMP message types. types instead of IGMP message types.
MLD Snooping Switches
- The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 24 of the 128 - The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 24 of the 128
bit DIP address are used to form the 48 bit DMAC addresses for bit DIP address are used to form the 48 bit DMAC addresses for
multicast groups, while [IPV6-TOKEN] describes the mapping for multicast groups, while [IPV6-TOKEN] describes the mapping for
token ring DMAC addresses by using three low-order bits. The token ring DMAC addresses by using three low-order bits. The
specification [IPV6-1394] makes use of a 6 bit channel number. specification [IPV6-1394] makes use of a 6 bit channel number.
- Multicast router discovery is accomplished using Neighbor - Multicast router discovery is accomplished using Neighbor
Discovery Protocol [NDP] for IPv6. NDP uses ICMPv6 message Discovery Protocol [NDP] for IPv6. NDP uses ICMPv6 message
types. types.
skipping to change at page 1, line 488 skipping to change at page 1, line 507
types is inflexible for the introduction of new message types. The types is inflexible for the introduction of new message types. The
second solution introduces the risk that new protocols which use second solution introduces the risk that new protocols which use
ICMPv6 and multicast DMAC addresses could be incorrectly identified ICMPv6 and multicast DMAC addresses could be incorrectly identified
as MLD. It is suggested that solution one is preferred when the as MLD. It is suggested that solution one is preferred when the
configuration option is provided. If this is not the case, then configuration option is provided. If this is not the case, then
the implementor should seriously consider making it available since the implementor should seriously consider making it available since
Neighbor Discovery messages would be among those that fall into Neighbor Discovery messages would be among those that fall into
this false positive case and are vital for the operational this false positive case and are vital for the operational
integrity of IPv6 networks. integrity of IPv6 networks.
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
The mapping from IP multicast addresses to multicast DMAC addresses The mapping from IP multicast addresses to multicast DMAC addresses
introduces a potentially enormous overlap. The structure of an introduces a potentially enormous overlap. The structure of an
IPv6 multicast address is shown in the figure below. As a result, IPv6 multicast address is shown in the figure below. As a result,
MLD Snooping Switches
there are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses there are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses
which map into a single DMAC address in Ethernet and FDDI. This which map into a single DMAC address in Ethernet and FDDI. This
should be compared to 2**5 in the case of IPv4. should be compared to 2**5 in the case of IPv4.
Initial allocation of IPv6 multicast addresses as described in Initial allocation of IPv6 multicast addresses as described in
[RFC3307], however, cover only the lower 32 bits of group ID. [RFC3307], however, cover only the lower 32 bits of group ID.
While this reduces the problem of address ambiguity to group IDs While this reduces the problem of address ambiguity to group IDs
with different flag and scope values for now, it should be noted with different flag and scope values for now, it should be noted
that the allocation policy may change in the future. Because of that the allocation policy may change in the future. Because of
the potential overlap it is recommended that IPv6 address based the potential overlap it is recommended that IPv6 address based
skipping to change at page 1, line 538 skipping to change at page 1, line 558
Q3 Is it possible to forward multicast datagrams based on IP Q3 Is it possible to forward multicast datagrams based on IP
addresses (not routed)? In other words, could 224.1.2.3 and addresses (not routed)? In other words, could 224.1.2.3 and
239.129.2.3 be forwarded on different port-groups with 239.129.2.3 be forwarded on different port-groups with
unaltered TTL? unaltered TTL?
Q4 Are multicast datagrams within the range 224.0.0.1 to Q4 Are multicast datagrams within the range 224.0.0.1 to
224.0.0.255 forwarded on all ports whether or not IGMP Joins 224.0.0.255 forwarded on all ports whether or not IGMP Joins
have been sent? have been sent?
Q5 Are multicast frames within the MAC address range RFC DRAFT Considerations for IGMP and February 2005
01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports
MLD Snooping Switches MLD Snooping Switches
Q5 Are multicast frames within the MAC address range
01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports
whether or not IGMP joins have been sent? whether or not IGMP joins have been sent?
Q6 Does your switch support forwarding to ports on which IP Q6 Does your switch support forwarding to ports on which IP
multicast routers are attached in addition to the ports where multicast routers are attached in addition to the ports where
IGMP Joins have been received? IGMP Joins have been received?
Q7 Is your IGMP snooping functionality fully implemented in Q7 Is your IGMP snooping functionality fully implemented in
hardware? hardware?
Q8 Is your IGMP snooping functionality partly software Q8 Is your IGMP snooping functionality partly software
skipping to change at page 1, line 585 skipping to change at page 1, line 606
---------------------------+---+---+---+---+---+---+ ---------------------------+---+---+---+---+---+---+
x Means that the answer was Yes. x Means that the answer was Yes.
(1) In some products (typically high-end) Yes; in others No. (1) In some products (typically high-end) Yes; in others No.
(2) Not at the time that the questionnaire was received (2) Not at the time that the questionnaire was received
but expected in the near future. but expected in the near future.
Revision History Revision History
[To RFC Editor: This section is to be removed at publication time] [To RFC Editor: This section is to be removed at publication time]
This section, while incomplete, is provided as a convenience to the RFC DRAFT Considerations for IGMP and February 2005
working group members. It will be removed when the document is
MLD Snooping Switches MLD Snooping Switches
This section, while incomplete, is provided as a convenience to the
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-12.txt: January 2005
Editorial changes only:
Update document references and author address; IPR and
disclaimer statements to adhere to RFC3668 requirements.
draft-ietf-magma-snoop-11.txt: April 2004 draft-ietf-magma-snoop-11.txt: April 2004
Editorial changes only: Editorial changes only:
Remove reference to IGMP/MLD Proxy (draft-ietf-magma- Remove reference to IGMP/MLD Proxy (draft-ietf-magma-
proxy-06.txt) to avoid perception of content dependency. proxy-06.txt) to avoid perception of content dependency.
Updated references to reflect current revisions, author Updated references to reflect current revisions, author
address. address.
skipping to change at page 1, line 629 skipping to change at page 1, line 658
Substantial comments Substantial comments
There were no substantial technical comments, but a list There were no substantial technical comments, but a list
of suggested wordings and clarifications to improve the of suggested wordings and clarifications to improve the
readability and RFC conformance of the draft. readability and RFC conformance of the draft.
Reference in Abstract removed. Improved wording in Reference in Abstract removed. Improved wording in
Introduction. Introduction.
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
Improved wording in recommendations section, clarified Improved wording in recommendations section, clarified
integrity checking for IPv6, removed security issues integrity checking for IPv6, removed security issues
which were really IGMP/MLD security issues. which were really IGMP/MLD security issues.
Editorial Changes Editorial Changes
Author information changes, TOC added, fixed a wrong Author information changes, TOC added, fixed a wrong
indentation following section 5. indentation following section 5.
MLD Snooping Switches
draft-ietf-magma-snoop-08.txt: June 2003 draft-ietf-magma-snoop-08.txt: June 2003
The changes in this version are the result of the WG chair The changes in this version are the result of the WG chair
review following the second WG last call. The last call itself review following the second WG last call. The last call itself
did not result in further comments. did not result in further comments.
Substantial comments Substantial comments
Requirements have now been replaced with Recommendations Requirements have now been replaced with Recommendations
throughout the draft, which is more appropriate for an throughout the draft, which is more appropriate for an
skipping to change at page 1, line 679 skipping to change at page 1, line 709
Moved reference to RFC2375 to the Informative section. Moved reference to RFC2375 to the Informative section.
draft-ietf-magma-snoop-07.txt: May 2003 draft-ietf-magma-snoop-07.txt: May 2003
The current version reflects comments made at the 56'th IETF The current version reflects comments made at the 56'th IETF
meeting and from the previous WG last call. The majority of meeting and from the previous WG last call. The majority of
changes appear in sections 2.1 and 2.2, and even the changes changes appear in sections 2.1 and 2.2, and even the changes
here are in reality not substantial. here are in reality not substantial.
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
Substantial comments Substantial comments
Section 2.1.1.(4): Changed wording for IGMP forwarding Section 2.1.1.(4): Changed wording for IGMP forwarding
section on when spoofing of General Queries should occur. section on when spoofing of General Queries should occur.
Added description of how to avoid IGMP version Added description of how to avoid IGMP version
incompatibility problems when doing said spoofing. incompatibility problems when doing said spoofing.
Section 2.1.2.(3): Clarification of incompatibility Section 2.1.2.(3): Clarification of incompatibility
problems in mixed IGMPv2 and IGMPv3 networks. Added problems in mixed IGMPv2 and IGMPv3 networks. Added
MLD Snooping Switches
recommendation for switches to implement some level of recommendation for switches to implement some level of
IGMPv3 Join recognition to reduce these problems. IGMPv3 Join recognition to reduce these problems.
Section 2.2: Advice following the briefing [IETF56], that Section 2.2: Advice following the briefing [IETF56], that
in some cases disabling IGMP snooping functionality is in some cases disabling IGMP snooping functionality is
the only 'solution' the only 'solution'
Section 6, IPv6 Considerations: added descriptions of Section 6, IPv6 Considerations: added descriptions of
behavior involving the IPv6 version of the null IP Source behavior involving the IPv6 version of the null IP Source
Address (to parallel the IPv4 behaviors). Address (to parallel the IPv4 behaviors).
skipping to change at page 1, line 730 skipping to change at page 1, line 761
Section 2.1.1.(4): Allow the router port to be excluded Section 2.1.1.(4): Allow the router port to be excluded
from the General Query messages from the General Query messages
Section 2.1.1.(6): Replace description of timing out Section 2.1.1.(6): Replace description of timing out
older entries with a reference to IGMP/MLD Proxying. older entries with a reference to IGMP/MLD Proxying.
Section 2.1.2.(3): Replaced description of timeout Section 2.1.2.(3): Replaced description of timeout
mechanism with a reference to IGMP/MLD. mechanism with a reference to IGMP/MLD.
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
Section 2.1.2.(4) Expanded rationale to discourage Section 2.1.2.(4) Expanded rationale to discourage
leaking info between IPv4 and IPv6 groups. leaking info between IPv4 and IPv6 groups.
Section 3: more strongly encourage the use of a Section 3: more strongly encourage the use of a
configuration option for selection of ICMPv6 message configuration option for selection of ICMPv6 message
types. types.
Editorial comments. Editorial comments.
MLD Snooping Switches
Hyphenation problem resolved for groff by setting then ms Hyphenation problem resolved for groff by setting then ms
HY register to zero, disabling all forms for the entire HY register to zero, disabling all forms for the entire
document document
(".hy 0" and ".nr" worked only as far as the following (".hy 0" and ".nr" worked only as far as the following
ms macro). ms macro).
Sections moved around - again - to comply with Sections moved around - again - to comply with
rfc2223bis-03 draft. Added copyright notice after memo rfc2223bis-03 draft. Added copyright notice after memo
status. Removed table of contents as the draft is fairly status. Removed table of contents as the draft is fairly
short. Corrected a reference typo. short. Corrected a reference typo.
skipping to change at page 1, line 780 skipping to change at page 1, line 812
References splitted in normative and informative sections, References splitted in normative and informative sections,
other related references added. other related references added.
Abstract shortened. Abstract shortened.
Changed all occurances of MUST, MAY etc. to lowercase to Changed all occurances of MUST, MAY etc. to lowercase to
reflect that this is not a standards track document. reflect that this is not a standards track document.
Sections moved around so they appear in the required order. Sections moved around so they appear in the required order.
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
draft-ietf-magma-snoop-04.txt: November 2002 draft-ietf-magma-snoop-04.txt: November 2002
Editorial changes only. 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 Add references to and become consistant with the current
IGMP proxy draft, IGMP proxy draft,
MLD Snooping Switches
Unrecognized IGMP packets should not be ignored because Unrecognized IGMP packets should not be ignored because
"mbz" fields are not zero since packets from future "mbz" fields are not zero since packets from future
versions are expected to maintain consistency. versions are expected to maintain consistency.
Corrections related to IGMP Querier election process. Corrections related to IGMP Querier election process.
Add clarification to how lists of router ports may be Add clarification to how lists of router ports may be
assembled. assembled.
skipping to change at page 1, line 829 skipping to change at page 1, line 863
IPv6 Considerations: IPv6 Considerations:
Clarifications regarding address ranges FF00::, FF01:: Clarifications regarding address ranges FF00::, FF01::
and all hosts FF02::1 in relation to data forwarding. and all hosts FF02::1 in relation to data forwarding.
draft-ietf-magma-snoop-02.txt: June 2002 draft-ietf-magma-snoop-02.txt: June 2002
Status section removes document history; moved into this Status section removes document history; moved into this
section instead. section instead.
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
Introduction restores text from the -00 revision that Introduction restores text from the -00 revision that
describes snooping and its goals describes snooping and its goals
IGMP flooding rules eased, allowing management option to IGMP flooding rules eased, allowing management option to
broaden beyond "routers only". broaden beyond "routers only".
Removed a should/MAY inconsistancy between IPv4 Forwarding and Removed a should/MAY inconsistancy between IPv4 Forwarding and
IPv6 processing of checksums. IPv6 processing of checksums.
MLD Snooping Switches
IGMP Forwarding Rules: clarify text describing processing of IGMP Forwarding Rules: clarify text describing processing of
non-zero reserved fields. non-zero reserved fields.
Data Forwarding Rules, item 3 is changed from "MUST forward to Data Forwarding Rules, item 3 is changed from "MUST forward to
all ports" to "MAY"; item 4 default changes from "MUST" to all ports" to "MAY"; item 4 default changes from "MUST" to
"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.
skipping to change at page 1, line 877 skipping to change at page 1, line 912
5. References 5. References
5.1. Normative References 5.1. Normative References
[BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges"
[IGMPv3] Cain, B., "Internet Group Management Protocol, Version [IGMPv3] Cain, B., "Internet Group Management Protocol, Version
3", RFC3376, October 2002. 3", RFC3376, October 2002.
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
[IPV6-1394] Fujisawa, K. and Onoe, A., "Transmission of IPv6 [IPV6-1394] Fujisawa, K. and Onoe, A., "Transmission of IPv6
Packets over IEEE 1394 Networks", RFC3146, October Packets over IEEE 1394 Networks", RFC3146, October
2001. 2001.
[IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over [IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC2464, December 1998. Ethernet Networks", RFC2464, December 1998.
MLD Snooping Switches
[IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI [IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", RFC2467, December 1998. Networks", RFC2467, December 1998.
[IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S., "Transmission [IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S., "Transmission
of IPv6 Packets over Token Ring Networks", RFC2470, of IPv6 Packets over Token Ring Networks", RFC2470,
December 1998. December 1998.
[MLD] Deering, S., Fenner, B. and Haberman, B. "Multicast [MLD] Deering, S., Fenner, B. and Haberman, B. "Multicast
Listener Discovery (MLD) for IPv6", RFC2710, October Listener Discovery (MLD) for IPv6", RFC2710, October
1999. 1999.
[MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery [MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", draft-vida-mld-v2-08.txt, Version 2 (MLDv2) for IPv6", RFC3810, June 2004.
December 2003.
[MRDISC] Biswas, S., Cain, B. and Haberman, B., "Multicast [MRDISC] Haberman, B. and Martin, J. "Multicast Router
Router Discovery", draft-ietf-magma-mrdisc-00.txt, Discovery", draft-ietf-magma-mrdisc-03.txt, September
February 2004. 2004.
[NDP] Narten, T., Nordmark, E. and Simpson, W., "Neighbor [NDP] Narten, T., Nordmark, E. and Simpson, W., "Neighbor
Discovery for IP Version 6 {IPv6)", RFC2461, December Discovery for IP Version 6 {IPv6)", RFC2461, December
1998. 1998.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", [RFC1112] Deering, S., "Host Extensions for IP Multicasting",
RFC1112, August 1989. RFC1112, August 1989.
[RFC2026] Bradner, S. "The Internet Standards Process --
Revision 3", RFC2026, October 1996.
[RFC2236] Fenner, W., "Internet Group Management Protocol, [RFC2236] Fenner, W., "Internet Group Management Protocol,
Version 2", RFC2236, November 1997. Version 2", RFC2236, November 1997.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6
Multicast Addresses", RFC3307, August 2002. Multicast Addresses", RFC3307, August 2002.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", RFC3668, February 2004.
5.2. Informative References 5.2. Informative References
[CISCO] [CISCO]
Cisco Tech Notes, "Multicast In a Campus Network: CGMP and Cisco Tech Notes, "Multicast In a Campus Network: CGMP and
IGMP snooping", http://www.cisco.com/warp/public/473/22.html IGMP snooping", http://www.cisco.com/warp/public/473/22.html
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
[IANA] Internet Assigned Numbers Authority, "Internet [IANA] Internet Assigned Numbers Authority, "Internet
Multicast Addresses", Multicast Addresses",
http://www.iana.org/assignments/multicast-addresses http://www.iana.org/assignments/multicast-addresses
MLD Snooping Switches
[IETF56] Briefing by Dave Thaler, Microsoft, presented to the [IETF56] Briefing by Dave Thaler, Microsoft, presented to the
MAGMA WG at the 56'th IETF meeting in San Francisco, MAGMA WG at the 56'th IETF meeting in San Francisco,
http://www.ietf.org/proceedings/03mar/index.html http://www.ietf.org/proceedings/03mar/index.html
[MSOFT] Microsoft support article Q223136, "Some LAN Switches [MSOFT] Microsoft support article Q223136, "Some LAN Switches
with IGMP Snooping Stop Forwarding Multicast Packets with IGMP Snooping Stop Forwarding Multicast Packets
on RRAS Startup", on RRAS Startup",
http://support.microsoft.com/support/articles/Q223/1/36.ASP
http://support.microsoft.com/support/articles/Q223/1/36.ASP
6. Security Considerations 6. Security Considerations
Under normal network operation, the snooping switch is expected to Under normal network operation, the snooping switch is expected to
improve overall network performance by limiting the scope of improve overall network performance by limiting the scope of
multicast flooding to a smaller portion of the local network. In multicast flooding to a smaller portion of the local network. In
the event of forged IGMP messages, the benefits of using a snooping the event of forged IGMP messages, the benefits of using a snooping
switch might be reduced or eliminated. switch might be reduced or eliminated.
Security considerations for IGMPv3 at the network layer of the Security considerations for IGMPv3 at the network layer of the
skipping to change at page 1, line 974 skipping to change at page 1, line 1010
should be sent to all multicast routers as well as the current should be sent to all multicast routers as well as the current
Querier. Querier.
- It is possible for a host on the local network to generate - It is possible for a host on the local network to generate
Current-State Report Messages that would cause the switch to Current-State Report Messages that would cause the switch to
incorrectly believe that there is a multicast listener on the incorrectly believe that there is a multicast listener on the
same network segment as the originator of the forged message. same network segment as the originator of the forged message.
This will cause unrequested multicast packets to be forwarded This will cause unrequested multicast packets to be forwarded
into the network segments between the source and the router. into the network segments between the source and the router.
If the router requires that all Multicast Report messages be If the router requires that all Multicast Report messages be
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
authenticated as described in section 9.4 of [IGMPv3], it will authenticated as described in section 9.4 of [IGMPv3], it will
discard the forged Report message from the host inside the discard the forged Report message from the host inside the
network in the same way that it would discard one which network in the same way that it would discard one which
originates from a remote location. It is worth noting that if originates from a remote location. It is worth noting that if
MLD Snooping Switches
the router accepts unauthenticated Report messages by virtue of the router accepts unauthenticated Report messages by virtue of
them having arrived over a network interface associated with them having arrived over a network interface associated with
the internal network, investigating the affected network the internal network, investigating the affected network
segments will quickly narrow the search for the source of the segments will quickly narrow the search for the source of the
forged messages. forged messages.
- As noted in [IGMPv3], there is little motivation for an - As noted in [IGMPv3], there is little motivation for an
attacker to forge a Membership report message since joining a attacker to forge a Membership report message since joining a
group is generally an unprivileged operation. The sender of group is generally an unprivileged operation. The sender of
the forged Membership report will be the only recipient of the the forged Membership report will be the only recipient of the
skipping to change at page 1, line 1015 skipping to change at page 1, line 1053
Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka
Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret
Wasserman for comments and suggestions on this document. Wasserman for comments and suggestions on this document.
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, Thrane & Thrane Hewlett-Packard, Vitesse Semiconductor Corporation, Thrane & Thrane
The ordering of these names do not necessarily correspond to the The ordering of these names do not necessarily correspond to the
column numbers in the response table. column numbers in the response table.
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches MLD Snooping Switches
8. Authors' Addresses 8. Authors' Addresses
Morten Jagd Christensen Morten Jagd Christensen
Thrane & Thrane Thrane & Thrane
Lundtoftegaardsvej 93 D Lundtoftegaardsvej 93 D
2800 Lyngby 2800 Lyngby
DENMARK DENMARK
email: mjc@tt.dk email: mjc@tt.dk
Karen Kimball Karen Kimball
Hewlett-Packard Hewlett-Packard
8000 Foothills Blvd. 8000 Foothills Blvd.
Roseville, CA 95747 Roseville, CA 95747
USA USA
email: karen.kimball@hp.com email: karen.kimball@hp.com
Frank Solensky Frank Solensky
West Ridge Networks Calix Networks
25 Porter Rd. 43 Nanog Park
Littleton, MA 01460 Acton, MA 01720
USA USA
email: fsolensky@WestRidgeNetworks.com email: frank.solensky@calix.com
9. IETF IPR Statement 9. IETF IPR Statement
"The IETF takes no position regarding the validity or scope of any "The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
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 [RFC-2026]. Copies standards-related documentation can be found in [RFC-2026]. Copies
of claims of rights made available for publication and any of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use
of such proprietary rights by implementors or users of this of such proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat." specification can be obtained from the IETF Secretariat."
10. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
MLD Snooping Switches
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages must be followed, or as required to translate it into languages
other than English. other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein are provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgement: Acknowledgement:
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
RFC DRAFT Considerations for IGMP and February 2005
MLD Snooping Switches MLD Snooping Switches
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IGMP Snooping Recommendations . . . . . . . . . . . . . . . 3 2. IGMP Snooping Recommendations . . . . . . . . . . . . . . . 3
2.1. Forwarding rules . . . . . . . . . . . . . . . . . . . . . 3 2.1. Forwarding rules . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . . . 3 2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . . . 4
2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . . . 6 2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . . . 6
2.2. IGMP snooping-related problems . . . . . . . . . . . . . . 8 2.2. IGMP snooping-related problems . . . . . . . . . . . . . . 8
3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 9 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 9
4. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 11 4. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 11
4. Revision History . . . . . . . . . . . . . . . . . . . . . . 12 4. Revision History . . . . . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Normative References . . . . . . . . . . . . . . . . . . . 18 5.1. Normative References . . . . . . . . . . . . . . . . . . . 18
5.2. Informative References . . . . . . . . . . . . . . . . . . 19 5.2. Informative References . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
 End of changes. 59 change blocks. 
68 lines changed or deleted 114 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/