doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc4489.txt b/doc/rfc/rfc4489.txt
new file mode 100644
index 0000000..70eb824
--- /dev/null
+++ b/doc/rfc/rfc4489.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                          J-S. Park
+Request for Comments: 4489                                     M-K. Shin
+Updates: 3306                                                   H-J. Kim
+Category: Standards Track                                           ETRI
+                                                              April 2006
+
+
+      A Method for Generating Link-Scoped IPv6 Multicast Addresses
+
+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
+
+   This document specifies an extension to the multicast addressing
+   architecture of the IPv6 protocol.  The extension allows the use of
+   Interface Identifiers (IIDs) to allocate multicast addresses.  When a
+   link-local unicast address is configured at each interface of a node,
+   an IID is uniquely determined.  After that, each node can generate
+   its unique multicast addresses automatically without conflicts.  The
+   alternative method for creating link-local multicast addresses
+   proposed in this document is better than known methods like unicast-
+   prefix-based IPv6 multicast addresses.  This memo updates RFC 3306.
+
+Table of Contents:
+
+   1. Introduction ....................................................2
+   2. Applicability ...................................................2
+   3. Link-Scoped Multicast Address Format ............................3
+   4. Example .........................................................3
+   5. Consideration of Lifetime .......................................4
+   6. Security Considerations .........................................4
+   7. Acknowledgements ................................................4
+   8. References ......................................................5
+
+
+
+
+
+
+
+
+Park, et al.                Standards Track                     [Page 1]
+
+RFC 4489               Link-Scoped IPv6 Multicast             April 2006
+
+
+1.  Introduction
+
+   This document defines an extension to the multicast portion of the
+   IPv6 addressing architecture [RFC4291].  The current architecture
+   does not contain any built-in support for dynamic address allocation.
+   The extension allows for use of IIDs to allocate multicast addresses.
+   When a link-local unicast address is configured at each interface of
+   a node, an IID is uniquely determined.  After that, each node can
+   generate its unique multicast addresses automatically without
+   conflicts.  That is, these addresses could safely be configured at
+   any time after Duplicate Address Detection (DAD) has completed.
+
+   This method for the link-local scope is preferred over unicast-
+   prefix-based IPv6 multicast addresses [RFC3306], since by delegating
+   multicast addresses using the IID, each node can generate its
+   multicast addresses automatically without allocation servers.  This
+   method works better than the unicast-prefix-based method with
+   applications in serverless environments such as ad-hoc and network
+   mobility.  This document restricts the usage of defined fields such
+   as the scop, plen, and network prefix fields of [RFC3306].
+   Therefore, this document specifies encoded information for link-local
+   scope in multicast addresses.
+
+   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 [RFC2119].
+
+2.  Applicability
+
+   The allocation technique in this document is designed to be used in
+   any environment in which link-local scope IPv6 multicast addresses
+   are assigned or selected.  This method goes especially well with
+   nodes supplying multicast services in a zeroconf/serverless
+   environment.  For example, multicast addresses less than or equal to
+   link-local scope are themselves generated by nodes supplying
+   multicast services without conflicts.  Also, hosts that are supplied
+   multicast services from multicast servers then make multicast
+   addresses of multicast servers using ND (address resolution) and
+   well-known group IDs [RFC2461].
+
+   Consequently, this technique MUST only be used for link scoped
+   multicast addresses.  If you want to use multicast addresses greater
+   than link-local scope, you need to use other methods as described in
+   [RFC3306].
+
+
+
+
+
+
+
+Park, et al.                Standards Track                     [Page 2]
+
+RFC 4489               Link-Scoped IPv6 Multicast             April 2006
+
+
+3.  Link-Scoped Multicast Address Format
+
+   This document specifies a new format that incorporates IID in the
+   link-local scope multicast addresses.
+
+   Figure 1 illustrates the new format for link-scoped multicast
+   addresses.
+
+      |   8    |  4 |  4 |   8    |    8   |       64       |    32    |
+      +--------+----+----+--------+--------+----------------+----------+
+      |11111111|flgs|scop|reserved|  plen  |       IID      | group ID |
+      +--------+----+----+--------+--------+----------------+----------+
+
+           Figure 1.  Link-Scoped Multicast IPv6 Address Format
+
+   The flgs, scop, and plen fields are used to identify whether an
+   address is a multicast address, as follows:
+
+    1. flgs MUST be "0011".
+
+    2. scop MUST be <= 2.
+
+    3. The reserved field MUST be zero.
+
+    4. The "plen" field is a special value, "1111 1111" (decimal 255).
+
+   The IID field (replacing the 64-bit prefix field from [RFC3306]) is
+   used to distinguish each node from others.  Given the use of this
+   method for link-local scope, the IID embedded in the multicast
+   address MUST only come from the IID of the link-local unicast address
+   on the interface after DAD has completed.  That is, the creation of
+   the multicast address MUST only occur after DAD has completed as part
+   of the auto-configuration process.
+
+   Group ID is generated to indicate a multicast application and is used
+   to guarantee its uniqueness only in the host.  It may also be set on
+   the basis of the guidelines outlined in [RFC3307].
+
+4.  Example
+
+   In an Ethernet environment, if the link-local unicast address is
+   FE80::A12:34FF:FE56:7890, the link-scoped multicast prefix of the
+   node is FF32:00FF:A12:34FF:FE56:7890::/96.
+
+
+
+
+
+
+
+
+Park, et al.                Standards Track                     [Page 3]
+
+RFC 4489               Link-Scoped IPv6 Multicast             April 2006
+
+
+5.  Consideration of Lifetime
+
+   Generally, link-scoped multicast addresses have no lifetime, because
+   link-local unicast addresses also have no lifetime.  However, this is
+   not true in the mobile environment.  Even though multicast addresses
+   are created from the unique IIDs of unicast addresses, their useful
+   lifetime is linked to the period during which the IID is known to be
+   unique.  Thus, conflict is possible between IIDs, due to a new node
+   in merged network that uses the same IID as a powered node.
+
+   In this scenario, DAD also fails to guarantee uniqueness of the
+   unicast address, but this document does not try to address this
+   issue.
+
+6.  Security Considerations
+
+   The uniqueness of multicast addresses using this method is guaranteed
+   by the DAD process.  So, a secure DAD process is needed for stability
+   of this method.  This document proposes the mechanism in [RFC3041]
+   for this purpose.
+
+   [RFC3041] describes the privacy extension to IPv6 stateless address
+   autoconfiguration to configure the IID of non-link-local scope
+   unicast addresses.  [RFC3041] cannot be used for making a link-local
+   unicast address, and hence it cannot be used to create an IID for
+   link-scoped multicast address.  However, as [RFC3041] does not
+   protect the privacy of link-local unicast addresses, it does not seem
+   to be required to protect the privacy of IID-based link-local
+   multicast addresses.
+
+7.  Acknowledgements
+
+   We would like to thank Dave Thaler and Brian Haberman for their
+   comments related to the consistency between the unicast prefix-based
+   multicast document and this one.  Special thanks are due to Erik
+   Nordmark and Pekka Savola for valuable comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park, et al.                Standards Track                     [Page 4]
+
+RFC 4489               Link-Scoped IPv6 Multicast             April 2006
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
+              Discovery for IP Version 6 (IPv6)", RFC 2461, December
+              1998..ti  3
+
+   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
+              Stateless Address Autoconfiguration in IPv6", RFC 3041,
+              January 2001.
+
+   [RFC3306]  Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
+              Multicast Addresses", RFC 3306, August 2002.
+
+   [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
+              Addresses", RFC 3307, August 2002.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
+Authors' Addresses
+
+   Jung-Soo Park
+   ETRI PEC
+   161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
+
+   Phone: +82 42 860 6514
+   EMail: pjs@etri.re.kr
+
+
+   Myung-Ki Shin
+   ETRI PEC
+   161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
+
+   Phone: +82 42 860 4847
+   EMail: myungki.shin@gmail.com
+
+
+   Hyoung-Jun Kim
+   ETRI PEC
+   161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
+
+   Phone: +82 42 860 6576
+   EMail: khj@etri.re.kr
+
+
+
+Park, et al.                Standards Track                     [Page 5]
+
+RFC 4489               Link-Scoped IPv6 Multicast             April 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 currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Park, et al.                Standards Track                     [Page 6]
+