idnits 2.17.1 draft-ietf-ipv6-link-scoped-mcast-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 263. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2004) is 7070 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 2461' is defined on line 194, but no explicit reference was found in the text == Unused Reference: 'RFC 3956' is defined on line 213, but no explicit reference was found in the text == Unused Reference: 'SSM ARCH' is defined on line 216, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Working Group J-S. Park 2 INTERNET DRAFT ETRI 3 Expires: June 2005 M-K. Shin 4 ETRI/NIST 5 H-J. Kim 6 ETRI 7 December 2004 9 Link Scoped IPv6 Multicast Addresses 10 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance 17 with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other docu- 26 ments at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in pro- 28 gress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 2005. 38 Abstract 40 This document specifies an extension to the multicast addressing 41 architecture of the IPv6 protocol. The extension allows for the use 42 of Interface Identifiers (IIDs) to allocate multicast addresses. 43 When a link-local unicast address is configured at each interface 44 of a node, an IID is uniquely determined. After that, each node 45 can generate their unique multicast addresses automatically without 46 conflicts. Basically, this document proposes an alternative method 47 for creating link-local multicast addresses over a known method 48 like unicast-prefix-based IPv6 multicast addresses. It is preferred 49 to use this method for link-local scope rather than unicast- 50 prefix-based IPv6 multicast addresses. This memo update RFC3306. 52 Table of Contents: 54 1. Introduction................................................2 55 2. Applicability...............................................2 56 3. Link Scoped Multicast Address Format........................3 57 4. Example ....................................................3 58 5. Consideration of Lifetime ..................................3 59 6. Security Considerations.....................................4 60 7. Acknowledgments.............................................4 61 8. References..................................................4 62 Author's Addresses.............................................5 64 1. Introduction 66 This document defines an extension to the multicast portion of the 67 IPv6 addressing architecture [RFC 3513]. The current architecture 68 does not contain any built-in support for dynamic address 69 allocation. The extension allows for use of IIDs to allocate 70 multicast addresses. When a link-local unicast address is 71 configured at each interface of a node, an IID is uniquely 72 determined. After that, each node can generate their unique 73 multicast addresses automatically without conflicts. That is, 74 these addresses could safely be configured at any time after DAD 75 (Duplicate Address Detection) has completed. 77 Basically, it is preferred to use this method for the link-local 78 scope rather than unicast-prefix-based IPv6 multicast addresses 79 [RFC 3306]. This document restricts the usage of defined fields 80 such as scop, plen and network prefix fields of [RFC 3306]. 81 Therefore, this document specifies encoded information for link- 82 local scope in multicast addresses. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 86 this document are to be interpreted as described in [RFC 2119]. 88 2. Applicability 90 The allocation technique in this document is designed to be used in 91 any environment in which link-local scope IPv6 multicast addresses 92 are assigned or selected. Especially, this method goes well with 93 nodes supplying multicast services in a zeroconf/serverless 94 environment. For example, multicast addresses less than or equal 95 to link-local scope are themselves generated by nodes supplying 96 multicast services without conflicts. Also, hosts which are 97 supplied multicast services from multicast servers then make 98 multicast addresses of multicast servers using ND (address 99 resolution) and well-known group IDs. 101 Consequently, this technique MUST only be used for link scoped 102 multicast addresses. If you want to use multicast addresses 103 greater than link-local scope, you need to use other methods as 104 described in [RFC 3306]. 106 3. Link Scoped Multicast Address Format 108 This document specifies a new format that incorporates IID in the 109 link-local scope multicast addresses. 111 Figure 1 illustrates the new format for link scoped multicast 112 addresses. 114 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 115 +--------+----+----+--------+--------+----------------+----------+ 116 |11111111|flgs|scop|reserved| plen | IID | group ID | 117 +--------+----+----+--------+--------+----------------+----------+ 119 Figure 1: Link scoped multicast IPv6 address format 121 Flgs, scop, and plen fields are used to identify whether an address 122 is a multicast address as specified in this document as follows: 123 1. flgs MUST be "0011". 124 2. scop MUST be <= 2. 125 3. The reserved field MUST be zero. 126 4. "plen" field is a special value "1111 1111" (decimal 255). 128 The IID field (replacing the 64-bit prefix field from [RFC 3306]) 129 is used to distinguish each node from others. This value is 130 obtained from the IEEE EUI-64 based interface identifier of the 131 link-local unicast IPv6 address. Given the use of this method for 132 link-local scope, the IID embedded in the multicast address MUST 133 only come from the IID of the link-local unicast address on the 134 interface after DAD has completed. That is, the creation of the 135 multicast address MUST only occur after DAD has completed as part 136 of the auto-configuration process. 138 Group ID is generated to indicate a multicast application and is 139 used to guarantee its uniqueness only in the host. It may also be 140 set on the basis of the guidelines outlined in [RFC 3307]. 142 4. Example 144 This is an example of link scoped IPv6 multicast addresses. For 145 example in an ethernet environment, if the link-local unicast 146 address is FE80::A12:34FF:FE56:7890, the link scoped multicast 147 prefix of the node is FF32:00FF:A12:34FF:FE56:7890::/96. 149 5. Consideration of Lifetime 150 Generally, Link scoped multicast addresses have no lifetime because 151 link-local unicast addresses also have no lifetime. But, it is not 152 true in environment of mobile. Even though multicast addresses are 153 created from the unique IID of unicast address, their useful 154 lifetime is linked to the period during which the IID is known to 155 be unique. Thus, it is possible to conflict between IIDs, due to a 156 new node in merged network that uses the same IID as a powered 157 node. 159 This is a scenario where DAD also fails to guarantee the uniqueness 160 of the unicast address, so this document does not try to address 161 this issue. 163 6. Security Considerations 165 The uniqueness of multicast addresses using this method is 166 guaranteed by the DAD process. So, it is needed to get a secure 167 DAD process for stability of this method. This document proposes 168 the mechanism in [RFC 3041] for this purpose. 170 [RFC 3041] describes the privacy extension to IPv6 stateless 171 address autoconfiguration to how to configure the IID of non-link- 172 local scope unicast addresses. [RFC 3041] can not be used for 173 making a link-local unicast address, and hence it cannot be used to 174 create an IID for link-scoped multicast address. However, as [RFC 175 3041] does not protect the privacy of link-local unicast addresses, 176 it does not protect the privacy of link-local unicast addresses, it 177 does not seem to be required to protect the privacy of IID-based 178 link-local multicast addresses. 180 7. Acknowledgements 182 We would like to thank Dave Thaler and Brian Haberman for his 183 comments related to the consistency between the unicast prefix- 184 based multicast draft and this one. Special thanks are due to Erik 185 Nordmark and Pekka Savola for valuable comments. 187 8. References 189 Normative 191 [RFC 2119] S. Bradner, "Key words for use in RFCs to indicate 192 Requirement Levels", RFC 2119, March 1997. 194 [RFC 2461] T. Narten, E. Nordmark and W. Simpson, "Neighbor 195 Discovery for IP Version 6 (IPv6)", RFC 2461, 196 December 1998. 198 [RFC 3041] T. Narten and R. Draves, "Privacy Extensions for 199 Stateless Address Autoconfiguration in IPv6," 200 RFC 3041, April 2001. 202 [RFC 3306] B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6 203 Multicast Addresses," RFC 3306, August 2002. 205 [RFC 3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast 206 Addresses," RFC 3307, August 2002. 208 [RFC 3513] R. Hinden and S. Deering, "IP Version 6 Addressing 209 Architecture", RFC 3513, April 2003. 211 Informative 213 [RFC 3956] P. Savola and B. Haberman, "Embedding the Rendezvous 214 Point (RP) Address in an IPv6 Multicast Address 216 [SSM ARCH] H. Holbrook and B. Cain, "Source-Specific Multicast 217 for IP", Work In Progress, September 2004. 219 Authors' Addresses 221 Jung-Soo Park 222 ETRI PEC 223 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea 224 Phone: +82 42 860 6514 225 Email: jspark@pec.etri.re.kr 227 Myung-Ki Shin 228 ETRI/NIST 229 820 West Diamond Avenue 230 Gaithersburg, MD 20899, USA 231 Tel : +1 301 975-3613 232 Fax : +1 301 590-0932 233 E-mail : mshin@nist.gov 235 Hyoung-Jun Kim 236 ETRI PEC 237 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea 238 Phone: +82 42 860 6576 239 Email: khj@etri.re.kr 241 Intellectual Property Statement 243 The IETF takes no position regarding the validity or scope of any 244 Intellectual Property Rights or other rights that might be claimed 245 to pertain to the implementation or use of the technology described 246 in this document or the extent to which any license under such 247 rights might or might not be available; nor does it represent that 248 it has made any independent effort to identify any such rights. 249 Information on the procedures with respect to rights in RFC 250 documents can be found in BCP 78 and BCP 79. 252 Copies of IPR disclosures made to the IETF Secretariat and any 253 assurances of licenses to be made available, or the result of an 254 attempt made to obtain a general license or permission for the use 255 of such proprietary rights by implementers or users of this 256 specification can be obtained from the IETF on-line IPR repository 257 at http://www.ietf.org/ipr. 259 The IETF invites any interested party to bring to its attention any 260 copyrights, patents or patent applications, or other proprietary 261 rights that may cover technology that may be required to implement 262 this standard. Please address the information to the IETF at 263 ietf-ipr@ietf.org. 265 Disclaimer of Validity 267 This document and the information contained herein are provided on 268 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 269 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 270 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 271 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 272 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 273 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 274 PARTICULAR PURPOSE. 276 Copyright Statement 278 Copyright (C) The Internet Society (2004). This document is 279 subject to the rights, licenses and restrictions contained in BCP 280 78, and except as set forth therein, the authors retain all their 281 rights. 283 Acknowledgment 285 Funding for the RFC Editor function is currently provided by the 286 Internet Society.