idnits 2.17.1 draft-ietf-ipv6-link-scoped-mcast-07.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 271. ** 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 seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 7 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 7071 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 208, but no explicit reference was found in the text == Unused Reference: 'RFC 3956' is defined on line 227, but no explicit reference was found in the text == Unused Reference: 'SSM ARCH' is defined on line 230, 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: 13 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Working Group J-S. Park 3 INTERNET DRAFT ETRI 4 Expires: June 2005 M-K. Shin 5 ETRI/NIST 6 H-J. Kim 7 ETRI 8 December 2004 10 Link Scoped IPv6 Multicast Addresses 11 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance 18 with RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups June also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and June be updated, replaced, or obsoleted by other docu- 27 ments at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in pro- 29 gress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 2005. 39 Abstract 41 This document specifies an extension to the multicast addressing 42 architecture of the IPv6 protocol. The extension allows for the use 43 of Interface Identifiers (IIDs) to allocate multicast addresses. 44 When a link-local unicast address is configured at each interface 45 of a node, an IID is uniquely determined. After that, each node 46 can generate their unique multicast addresses automatically without 47 conflicts. Basically, this document proposes an alternative method 48 for creating link-local multicast addresses over a known method 49 like unicast-prefix-based IPv6 multicast addresses. It is preferred 50 to use this method for link-local scope rather than unicast- 51 prefix-based IPv6 multicast addresses. This memo update RFC3306. 53 Table of Contents: 55 1. Introduction................................................2 56 2. Applicability...............................................2 57 3. Link Scoped Multicast Address Format........................3 58 4. Example ....................................................4 59 5. Consideration of Lifetime ..................................4 60 6. Security Considerations.....................................4 61 7. Acknowledgments.............................................4 62 8. References..................................................5 63 Author's Addresses.............................................5 65 1. Introduction 67 This document defines an extension to the multicast portion of the 68 IPv6 addressing architecture [RFC 3513]. The current architecture 69 does not contain any built-in support for dynamic address 70 allocation. The extension allows for use of IIDs to allocate 71 multicast addresses. When a link-local unicast address is 72 configured at each interface of a node, an IID is uniquely 73 determined. After that, each node can generate their unique 74 multicast addresses automatically without conflicts. That is, 75 these addresses could safely be configured at any time after DAD 76 (Duplicate Address Detection) has completed. 78 Basically, it is preferred to use this method for the link-local 79 scope rather than unicast-prefix-based IPv6 multicast addresses 80 [RFC 3306]. This document restricts the usage of defined fields 81 such as scop, plen and network prefix fields of [RFC 3306]. 82 Therefore, this document specifies encoded information for link- 83 local scope in multicast addresses. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "June", and "OPTIONAL" in 87 this document are to be interpreted as described in [RFC 2119]. 89 2. Applicability 91 The allocation technique in this document is designed to be used in 92 any environment in which link-local scope IPv6 multicast addresses 93 are assigned or selected. Especially, this method goes well with 94 nodes supplying multicast services in a zeroconf/serverless 95 environment. For example, multicast addresses less than or equal 96 to link-local scope are themselves generated by nodes supplying 97 multicast services without conflicts. Also, hosts which are 98 supplied multicast services from multicast servers then make 99 multicast addresses of multicast servers using ND (address 100 resolution) and well-known group IDs. 102 Consequently, this technique MUST only be used for link scoped 103 multicast addresses. If you want to use multicast addresses 104 greater than link-local scope, you need to use other methods as 105 described in [RFC 3306]. 107 3. Link Scoped Multicast Address Format 109 This document specifies a new format that incorporates IID 110 information in the multicast addresses. The idea of delegating 111 multicast addresses can be applicable to link-local scope. 113 Figure 1 illustrates the new format for link scoped multicast 114 addresses. 116 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 117 +--------+----+----+--------+--------+----------------+----------+ 118 |11111111|flgs|scop|reserved| LSM | IID | group ID | 119 +--------+----+----+--------+--------+----------------+----------+ 121 Figure 1: Link scoped multicast IPv6 address format 123 flgs MUST be "0011". (The first two bits set to zero by the 124 sending node and ignored on receipt). "flgs" MUST use the same 125 flag defined in section 4 of [RFC 3306]. 127 scop MUST be <= 2. It is preferred to use this method for the 128 link-local scope rather than unicast-prefix-based IPv6 multicast 129 addresses [RFC 3306]. But, the users can choose whichever they 130 wish and deem appropriate. 132 The reserved field MUST be zero. 134 LSM field MUST be "1111 1111" which maps to the plen field in [RFC 135 3306], whereas the plen field in [RFC 3306] MUST NOT be greater 136 than 64. 138 That is, flgs, scop, and plen fields are used to identify whether 139 an address is a multicast address as specified in this document. 141 The IID field is used to distinguish each node from others. And 142 this value is obtained from the IEEE EUI-64 based interface 143 identifier of the link-local unicast IPv6 address. Given the use 144 of this method for link-local scope, the IID embedded in the 145 multicast address MUST only come from the IID of the link-local 146 unicast address on the interface after DAD has completed. That is, 147 the creation of the multicast address MUST only occur after DAD has 148 completed as part of the auto-configuration process. 150 Group ID is generated to indicate a multicast application and is 151 used to guarantee its uniqueness only in the host. It June also be 152 set on the basis of the guidelines outlined in [RFC 3307]. 154 4. Example 156 This is an example of link scoped IPv6 multicast addresses. For 157 example in an ethernet environment, if the link-local unicast 158 address is FE80::A12:34FF:FE56:7890, the link scoped multicast 159 prefix of the node is FF32:00FF:A12:34FF:FE56:7890::/96. 161 5. Consideration of Lifetime 163 Generally, Link scoped multicast addresses have no lifetime because 164 link-local unicast addresses also have no lifetime. But, it is not 165 true in environment of mobile. Even though multicast addresses are 166 created from the unique IID of unicast address, their useful 167 lifetime is linked to the period during which the IID is known to 168 be unique. Thus, it is possible to conflict between IIDs, due to a 169 new node in merged network that uses the same IID and a powered 170 node. The document does not consider this case at this phase. It 171 is another challenging issue and out of scope of this document. 173 6. Security Considerations 175 The uniqueness of multicast addresses using this method is 176 guaranteed by the DAD process. So, it is needed to get a secure 177 DAD process for stability of this method. This document proposes 178 the mechanism in [RFC 3041] for this purpose. 180 [RFC 3041] describes the privacy extension to IPv6 stateless 181 address autoconfiguration for an IID and how to configure the 182 global-scope unicast addresses. The privacy extension method in 183 [RFC 3041] is triggered when a host receives a router advertisement 184 with a prefix information option carrying a global-scope prefix for 185 the purpose of address auto-configuration. That is, [RFC 3041] can 186 not be used for making a link-local unicast address. Since the IID 187 embedded in the link scoped multicast address MUST only come from 188 the IID of the link-local unicast address on the interface after 189 DAD has completed, the secure IID, generated by [RFC 3041], can not 190 be used for consisting of a link scoped multicast address. But, it 191 is possible to use secure IID for expanding the intensity of 192 security regardless of a difficulty of acquisition of multicast 193 server addresses. 195 7. Acknowledgements 196 We would like to thank Dave Thaler and Brian Haberman for his 197 comments related to the consistency between the unicast prefix- 198 based multicast draft and this one. Special thanks are due to Erik 199 Nordmark and Pekka Savola for valuable comments. 201 8. References 203 Normative 205 [RFC 2119] S. Bradner, "Key words for use in RFCs to indicate 206 Requirement Levels", RFC 2119, March 1997. 208 [RFC 2461] T. Narten, E. Nordmark and W. Simpson, "Neighbor 209 Discovery for IP Version 6 (IPv6)", RFC 2461, 210 December 1998. 212 [RFC 3041] T. Narten and R. Draves, "Privacy Extensions for 213 Stateless Address Autoconfiguration in IPv6," 214 RFC 3041, April 2001. 216 [RFC 3306] B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6 217 Multicast Addresses," RFC 3306, August 2002. 219 [RFC 3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast 220 Addresses," RFC 3307, August 2002. 222 [RFC 3513] R. Hinden and S. Deering, "IP Version 6 Addressing 223 Architecture", RFC 3513, April 2003. 225 Informative 227 [RFC 3956] P. Savola and B. Haberman, "Embedding the Rendezvous 228 Point (RP) Address in an IPv6 Multicast Address 230 [SSM ARCH] H. Holbrook and B. Cain, "Source-Specific Multicast 231 for IP", Work In Progress, September 2004. 233 Authors' Addresses 235 Jung-Soo Park 236 ETRI PEC 237 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea 238 Phone: +82 42 860 6514 239 Email: jspark@pec.etri.re.kr 241 Myung-Ki Shin 242 ETRI/NIST 243 820 West Diamond Avenue 244 Gaithersburg, MD 20899, USA 245 Tel : +1 301 975-3613 246 Fax : +1 301 590-0932 247 E-mail : mshin@nist.gov 249 Hyoung-Jun Kim 250 ETRI PEC 251 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea 252 Phone: +82 42 860 6576 253 Email: khj@etri.re.kr 255 Intellectual Property Statement 257 The IETF takes no position regarding the validity or scope of any 258 Intellectual Property Rights or other rights that might be claimed 259 to pertain to the implementation or use of the technology described 260 in this document or the extent to which any license under such 261 rights might or might not be available; nor does it represent that 262 it has made any independent effort to identify any such rights. 263 Information on the procedures with respect to rights in RFC 264 documents can be found in BCP 78 and BCP 79. 266 Copies of IPR disclosures made to the IETF Secretariat and any 267 assurances of licenses to be made available, or the result of an 268 attempt made to obtain a general license or permission for the use 269 of such proprietary rights by implementers or users of this 270 specification can be obtained from the IETF on-line IPR repository 271 at http://www.ietf.org/ipr. 273 The IETF invites any interested party to bring to its attention any 274 copyrights, patents or patent applications, or other proprietary 275 rights that June cover technology that June be required to implement 276 this standard. Please address the information to the IETF at 277 ietf-ipr@ietf.org. 279 Disclaimer of Validity 281 This document and the information contained herein are provided on 282 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 283 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 284 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 285 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 286 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 287 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 288 PARTICULAR PURPOSE. 290 Copyright Statement 292 Copyright (C) The Internet Society (2004). This document is 293 subject to the rights, licenses and restrictions contained in BCP 294 78, and except as set forth therein, the authors retain all their 295 rights. 297 Acknowledgment 299 Funding for the RFC Editor function is currently provided by the 300 Internet Society.