doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc4604.txt b/doc/rfc/rfc4604.txt
new file mode 100644
index 0000000..cf3544a
--- /dev/null
+++ b/doc/rfc/rfc4604.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                        H. Holbrook
+Request for Comments: 4604                                 Arastra, Inc.
+Updates: 3376, 3810                                              B. Cain
+Category: Standards Track                                Acopia Networks
+                                                             B. Haberman
+                                                                 JHU APL
+                                                             August 2006
+
+
+      Using Internet Group Management Protocol Version 3 (IGMPv3)
+      and Multicast Listener Discovery Protocol Version 2 (MLDv2)
+                     for Source-Specific Multicast
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Internet Group Management Protocol Version 3 (IGMPv3) and the
+   Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols
+   that allow a host to inform its neighboring routers of its desire to
+   receive IPv4 and IPv6 multicast transmissions, respectively.
+   Source-specific multicast (SSM) is a form of multicast in which a
+   receiver is required to specify both the network-layer address of the
+   source and the multicast destination address in order to receive the
+   multicast transmission.  This document defines the notion of an
+   "SSM-aware" router and host, and clarifies and (in some cases)
+   modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and
+   hosts to accommodate source-specific multicast.  This document
+   updates the IGMPv3 and MLDv2 specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+Holbrook, et al.            Standards Track                     [Page 1]
+
+RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006
+
+
+1.  Introduction
+
+   The Internet Group Management Protocol (IGMP) [RFC1112, IGMPv2,
+   IGMPv3] allows an IPv4 host to communicate IP multicast group
+   membership information to its neighboring routers.  IGMP version 3
+   (IGMPv3) [IGMPv3] provides the ability for a host to selectively
+   request or filter traffic from individual sources within a multicast
+   group.
+
+   The Multicast Listener Discovery Protocol (MLD) [RFC2710, MLDv2]
+   offers similar functionality for IPv6 hosts.  MLD version 2 (MLDv2)
+   provides the analogous "source filtering" functionality of IGMPv3 for
+   IPv6.
+
+   Due to the commonality of function, the term "Group Management
+   Protocol", or "GMP", will be used to refer to both IGMP and MLD.  The
+   term "Source Filtering GMP", or "SFGMP", will be used to refer
+   jointly to the IGMPv3 and MLDv2 group management protocols.
+
+   The use of source-specific multicast is facilitated by small changes
+   to the SFGMP protocols on both hosts and routers.  [SSM] defines
+   general requirements that must be followed by systems that implement
+   the SSM service model; this document defines the concrete application
+   of those requirements to systems that implement IGMPv3 and MLDv2.  In
+   doing so, this document defines modifications to the host and router
+   portions of IGMPv3 and MLDv2 for use with SSM, and presents a number
+   of clarifications to their behavior when used with SSM addresses.
+   This document updates the IGMPv3 and MLDv2 specifications.
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   In order to emphasize the parts of this document that modify the
+   existing protocol specifications ([RFC2710, MLDv2, IGMPv3]), as
+   opposed to merely clarify them, any protocol modifications are marked
+   with the tag "MODIFICATION".
+
+2.  Host Requirements for Source-Specific Multicast
+
+   This section defines the notion of an "SSM-aware" host and then goes
+   on to describe the API requirements and the SFGMP protocol
+   requirements of an SSM-aware host.  It is important to note that SSM
+   can be used by any host that supports source filtering APIs and whose
+   operating system supports the appropriate SFGMP.  The SFGMP
+
+
+
+
+Holbrook, et al.            Standards Track                     [Page 2]
+
+RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006
+
+
+   modifications described in this section make SSM work better on an
+   SSM-aware host, but they are not strict prerequisites for the use of
+   SSM.
+
+   The 232/8 IPv4 address range is currently allocated for SSM by IANA
+   [IANA-ALLOCATION].  In IPv6, the FF3x::/32 range (where 'x' is a
+   valid IPv6 multicast scope value) is reserved for SSM semantics
+   [RFC3306], although today SSM allocations are restricted to
+   FF3x::/96.  ([SSM] has a more thorough discussion of this topic.)  A
+   host that knows the SSM address range and is capable of applying SSM
+   semantics to it is described as an "SSM-aware" host.
+
+   A host or router may be configured to apply SSM semantics to
+   addresses other than those in the IANA-allocated range.  The GMP
+   module on a host or router SHOULD have a configuration option to set
+   the SSM address range(s).  If this configuration option exists, it
+   MUST default to the IANA-allocated SSM range.  The mechanism for
+   setting this configuration option MUST at least allow for manual
+   configuration.  Protocol mechanisms to set this option may be defined
+   in the future.
+
+2.1.  API Requirements
+
+   If the host IP module of an SSM-aware host receives a non-source-
+   specific request to receive multicast traffic sent to an SSM
+   destination address, it SHOULD return an error to the application, as
+   specified in [MSFAPI] (MODIFICATION).  On a non-SSM-aware host, an
+   application that uses the wrong API (e.g., "join(G)",
+   "IPMulticastListen(G,EXCLUDE(S1))" for IGMPv3, or
+   "IPv6MulticastListen(G,EXCLUDE(S2))" for MLDv2) to request delivery
+   of packets sent to an SSM address will not receive the requested
+   service, because an SSM-aware router (following the rules of this
+   document) will refuse to process the request, and the application
+   will receive no indication other than a failure to receive the
+   requested traffic.
+
+2.2.  GMP Requirements
+
+   This section defines the behavior of the SFGMP protocol module on an
+   SSM-aware host, including two modifications to the protocols as
+   described in [IGMPv3, MLDv2].  It also includes a number of
+   clarifications of protocol operations.  In doing so, it documents the
+   behavior of an SSM-aware host with respect to sending and receiving
+   the following GMP message types:
+
+      - IGMPv1/v2 and MLDv1 Reports (2.2.1)
+      - IGMPv3 and MLDv2 Reports (2.2.2)
+      - IGMPv1 Queries, IGMPv2 and MLDv1 General Queries (2.2.3)
+
+
+
+Holbrook, et al.            Standards Track                     [Page 3]
+
+RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006
+
+
+      - IGMPv2 Leave and MLDv1 Done (2.2.4)
+      - IGMPv2 and MLDv1 Group Specific Query (2.2.5)
+      - IGMPv3 and MLDv2 Group Specific Query (2.2.6)
+      - IGMPv3 and MLDv2 Group-and-Source Specific Query (2.2.7)
+
+2.2.1.  IGMPv1/v2 and MLDv1 Reports
+
+   An SSM-aware host operating according to [IGMPv3, MLDv2] could send
+   an IGMPv1, IGMPv2, or MLDv1 report for an SSM address when it is
+   operating in "older-version compatibility mode."  This is an
+   exceptional (error) condition, indicating that the router(s) cannot
+   provide the SFGMP support needed for SSM, and an error is logged when
+   the host enters compatibility mode for an SSM address, as described
+   below.  In this situation, it is likely that traffic sent to a
+   channel (S,G) will not be delivered to a receiving host that has
+   requested to receive channel (S,G).
+
+   [IGMPv3] and [MLDv2] specify that a host MAY allow an older-version
+   report to suppress its own IGMPv3 or MLDv2 Membership Record.  An
+   SSM-aware host, however, MUST NOT allow its report to be suppressed
+   in this situation (MODIFICATION).  Suppressing reports in this
+   scenario would provide an avenue for an attacker to deny SSM service
+   to other hosts on the link.
+
+2.2.2.  IGMPv3 and MLDv2 Reports
+
+   A host implementation may report more than one SSM channel in a
+   single report either by including multiple sources within a group
+   record or by including multiple group records.
+
+   A Group Record for a source-specific destination address may (under
+   normal operation) be any of the following types:
+
+      - MODE_IS_INCLUDE as part of a Current-State Record
+
+      - ALLOW_NEW_SOURCES as part of a State-Change Record
+
+      - BLOCK_OLD_SOURCES as part of a State-Change Record
+
+   A report may include both SSM destination addresses and non-source-
+   specific, i.e., Any-Source Multicast (ASM) destination addresses, in
+   the same message.
+
+   Additionally, a CHANGE_TO_INCLUDE_MODE record may be sent by a host
+   in some cases, for instance, when the SSM address range is changed
+   through configuration.  A router should process such a record
+   according to the normal SFGMP rules.
+
+
+
+
+Holbrook, et al.            Standards Track                     [Page 4]
+
+RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006
+
+
+   An SSM-aware host SHOULD NOT send any of the following record types
+   for an SSM address.
+
+      - MODE_IS_EXCLUDE as part of a Current-State Record
+
+      - CHANGE_TO_EXCLUDE_MODE as part of a Filter-Mode-Change Record
+
+   This is a MODIFICATION to [IGMPv3, MLDv2], imposing a restriction on
+   its use for SSM destination addresses.  The rationale is that EXCLUDE
+   mode does not apply to SSM addresses, and an SSM-aware router will
+   ignore MODE_IS_EXCLUDE and CHANGE_TO_EXCLUDE_MODE requests in the SSM
+   range, as described below.
+
+2.2.3.  IGMPv1 Queries, IGMPv2 and MLDv1 General Queries
+
+   If an IGMPv1 Query, or an IGMPv2 or MLDv1 General Query is received,
+   the SFGMP protocol specifications require the host to revert to the
+   older (IGMPv1, IGMPv2, or MLDv1) mode of operation on that interface.
+   If this occurs, the host will stop reporting source-specific
+   subscriptions on that interface and will start using IGMPv1, IGMPv2,
+   or MLDv1 to report interest in all SSM destination addresses,
+   unqualified by a source address.  As a result, SSM semantics will no
+   longer be applied to the multicast group address by the router.
+
+   A router compliant with this document would never generate an IGMPv1,
+   IGMPv2, or MLDv1 query for an address in the SSM range; thus, this
+   situation only occurs either if the router is not SSM-aware, or if
+   the host and the router disagree about the SSM address range (for
+   instance, if they have inconsistent manual configurations).
+
+   A host SHOULD log an error if it receives an IGMPv1, IGMPv2, or MLDv1
+   query for an SSM address (MODIFICATION).
+
+   In order to mitigate this problem, it must be administratively
+   assured that all routers on a given shared-medium network are
+   compliant with this document and are in agreement about the SSM
+   address range.
+
+2.2.4.  IGMPv2 Leave and MLDv1 Done
+
+   IGMP Leave and MLD Done messages are not processed by hosts.  IGMPv2
+   Leave and MLDv1 Done messages should not be sent for an SSM address,
+   unless the sending host has reverted to older-version compatibility
+   mode, with all the caveats described above.
+
+
+
+
+
+
+
+Holbrook, et al.            Standards Track                     [Page 5]
+
+RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006
+
+
+2.2.5.  IGMPv2 and MLDv1 Group Specific Query
+
+   If a host receives an IGMPv2 or MLDv1 Group Specific Query for an
+   address in any configured source-specific range, it should process
+   the query normally, as per [IGMPv3, MLDv2], even if the group queried
+   is a source-specific destination address.  The transmission of such a
+   query likely indicates either that the sending router is not
+   compliant with this document or that it is not configured with the
+   same SSM address range(s) as the receiving host.  A host SHOULD log
+   an error in this case (MODIFICATION).
+
+2.2.6.  IGMPv3 and MLDv2 Group-Specific Query
+
+   If an SSM-aware host receives an SFGMP Group-Specific Query for an
+   SSM address, it must respond with a report if the group matches the
+   source-specific destination address of any of its subscribed source-
+   specific channels, as specified in [IGMPv3, MLDv2].
+
+   The rationale for this is that, although in the current SFGMP
+   protocol specifications a router would have no reason to send one,
+   the semantics of such a query are well-defined in this range and
+   future implementations may have reason to send such a query.  Be
+   liberal in what you accept.
+
+2.2.7.  IGMPv3 and MLDv2 Group-and-Source-Specific Query
+
+   An SFGMP router typically uses a Group-and-Source-Specific Query to
+   query an SSM channel that a host has requested to leave via a
+   BLOCK_OLD_SOURCES record.  A host must respond to a Group-and-
+   Source-Specific Query for which the group and source in the query
+   match any channel for which the host has a subscription, as required
+   by [IGMPv3, MLDv2].  The use of an SSM address does not change this
+   behavior.
+
+   A host must be able to process a query with multiple sources listed
+   per group, again as required by [IGMPv3, MLDv2].  The use of an SSM
+   address does not modify the behavior of the SFGMPs in this regard.
+
+3.  Router Requirements for Source-Specific Multicast
+
+   Routers must be aware of the SSM address range in order to provide
+   the SSM service model.  A router that knows the SSM address range and
+   is capable of applying SSM semantics to it as described in this
+   section is described as an "SSM-aware" router.  An SSM-aware router
+   MAY have a configuration option to apply SSM semantics to addresses
+   other than the IANA-allocated range, but if such an option exists, it
+   MUST default to the IANA-allocated range.
+
+
+
+
+Holbrook, et al.            Standards Track                     [Page 6]
+
+RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006
+
+
+   This section documents the behavior of routers with respect to the
+   following types of SFGMP messages for source-specific destination
+   addresses:
+
+      - IGMPv3 and MLDv2 Reports (3.1)
+      - IGMPv3 and MLDv2 General Query (3.2)
+      - IGMPv3 and MLDv2 Group-Specific Query (3.3)
+      - IGMPv3 and MLDv2 Group-and-Source Specific Query (3.4)
+      - IGMPv1/v2 and MLDv1 Reports (3.5)
+      - IGMPv1/v2 and MLDv1 Queries (3.6)
+      - IGMPv2 Leave and MLDv1 Done (3.7)
+
+3.1.  IGMPv3 and MLDv2 Reports
+
+   SFGMP Reports are used to report source-specific subscriptions in the
+   SSM address range.  A router SHOULD ignore a group record of either
+   of the following types if it refers to an SSM destination address:
+
+         - MODE_IS_EXCLUDE Current-State Record
+
+         - CHANGE_TO_EXCLUDE_MODE Filter-Mode-Change Record
+
+   A router MAY choose to log an error in either case.  It MUST process
+   any other group records within the same report.  These behaviors are
+   MODIFICATIONS to [IGMPv3, MLDv2] to prevent non-source-specific
+   semantics from being applied to SSM addresses, and to avoid reverting
+   to older-version compatibility mode.
+
+   A CHANGE_TO_INCLUDE_MODE Filter-Mode-Change Record is processed per
+   the normal SFGMP rules; Section 2.2.2 describes a legitimate scenario
+   when this could occur.
+
+3.2.  IGMPv3 and MLDv2 General Queries
+
+   An SSM router sends periodic SFGMP General Queries as per the IGMPv3
+   and MLDv2 specifications.  No change in behavior is required for SSM.
+
+3.3.  IGMPv3 and MLDv2 Group-Specific Queries
+
+   SFGMP routers that support source-specific multicast may send group-
+   specific queries for addresses in the source-specific range.  This
+   specification does not explicitly prohibit such a message, although,
+   at the time of this writing, a router conformant to [IGMPv3, MLDv2]
+   would not send one.
+
+
+
+
+
+
+
+Holbrook, et al.            Standards Track                     [Page 7]
+
+RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006
+
+
+3.4.  IGMPv3 and MLDv2 Group-and-Source-Specific Queries
+
+   SFGMP Group-and-Source-Specific Queries are used when a receiver has
+   indicated that it is no longer interested in receiving traffic from a
+   particular (S,G) pair to determine if there are any remaining
+   directly-attached hosts with interest in that (S,G) pair.  Group-
+   and-Source-Specific Queries are used within the source-specific
+   address range when a router receives a BLOCK_OLD_SOURCES Record for
+   one or more source-specific groups.  These queries are sent normally,
+   as per [IGMPv3, MLDv2].
+
+3.5.  IGMPv1/v2 and MLDv1 Reports
+
+   An IGMPv1/v2 or MLDv1 report for an address in the source-specific
+   range could be sent by a non-SSM-aware host.  A router SHOULD ignore
+   all such reports and specifically SHOULD NOT use them to establish IP
+   forwarding state.  This is a MODIFICATION to [IGMPv3, MLDv2].  A
+   router MAY log an error if it receives such a report (also a
+   MODIFICATION).
+
+3.6.  IGMPv1/v2 and MLDv1 Queries
+
+   An SFGMP router that loses the querier election to a lower version
+   router must log an error, as specified by [IGMPv3, MLDv2].
+
+3.7.  IGMPv2 Leave and MLDv1 Done
+
+   An IGMPv2 Leave or MLDv1 Done message may be sent by a non-SSM-aware
+   host.  A router SHOULD ignore all such messages in the source-
+   specific address range and MAY log an error (MODIFICATION).
+
+4.  Security Considerations
+
+   The specific protocol modifications described in this document are
+   not known to create any security concerns that are not already
+   present when IGMPv3 or MLDv2 is used with ASM-style multicast.  The
+   reader is referred to [SSM] for an analysis of SSM-specific security
+   issues.
+
+   It is important that a router not accept non-source-specific
+   reception requests for an SSM destination address.  The rules of
+   [IGMPv3] and [MLDv2] require a router, upon receiving such a
+   membership report, to revert to earlier version compatibility mode
+   for the group in question.  If the router were to revert in this
+   situation, it would prevent an IGMPv3-capable host from receiving SSM
+   service for that destination address, thus creating a potential for
+   an attacker to deny SSM service to other hosts on the same link.
+
+
+
+
+Holbrook, et al.            Standards Track                     [Page 8]
+
+RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006
+
+
+5.  Acknowledgements
+
+   The authors would like to thank Vince Laviano, Nidhi Bhaskar, Steve
+   Deering, Toerless Eckert, and Pekka Savola for their input and
+   careful review.
+
+6.  Normative References
+
+   [IGMPv2]     Fenner, W., "Internet Group Management Protocol, Version
+                2", RFC 2236, November 1997.
+
+   [IGMPv3]     Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+                Thyagarajan, "Internet Group Management Protocol,
+                Version 3", RFC 3376, October 2002.
+
+   [MSFAPI]     Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
+                Extensions for Multicast Source Filters", RFC 3678,
+                January 2004.
+
+   [RFC1112]    Deering, S., "Host extensions for IP multicasting", STD
+                5, RFC 1112, August 1989.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SSM]        Holbrook, H. and B. Cain, "Source-Specific Multicast for
+                IP", RFC 4607, August 2006.
+
+   [MLDv2]      Vida, R. and L. Costa, "Multicast Listener Discovery
+                Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
+
+   [RFC2710]    Deering, S., Fenner, W., and B. Haberman, "Multicast
+                Listener Discovery (MLD) for IPv6", RFC 2710, October
+                1999.
+
+8.  Informative References
+
+   [IANA-ALLOC] Internet Assigned Numbers Authority,
+                http://www.iana.org/assignments/multicast-addresses.
+
+   [RFC3306]    Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
+                Multicast Addresses", RFC 3306, August 2002.
+
+
+
+
+
+
+
+
+
+Holbrook, et al.            Standards Track                     [Page 9]
+
+RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006
+
+
+Authors' Addresses
+
+   Hugh Holbrook
+   Arastra, Inc.
+   P.O. Box 10905
+   Palo Alto, CA 94303
+
+   Phone: +1 650 331-1620
+   EMail: holbrook@arastra.com
+
+
+   Brad Cain
+   Acopia Networks
+
+   EMail: bcain99@gmail.com
+
+
+   Brian Haberman
+   Johns Hopkins University Applied Physics Lab
+   11100 Johns Hopkins Road
+   Laurel, MD  20723-6099
+
+   EMail: brian@innovationslab.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holbrook, et al.            Standards Track                    [Page 10]
+
+RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   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.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances 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 proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Holbrook, et al.            Standards Track                    [Page 11]
+