idnits 2.17.1 draft-zhang-coordinate-based-ipv6-multicast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 23, 2019) is 1615 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT haihong zhang 3 Intended Status: Standards Track lin luo 4 Expires: May 26, 2020 H3C Corporation 5 Qianli Zhang 6 Tsinghua University 7 November 23, 2019 9 Coordinate-Based Dynamic IPv6 Multicast Addresses Allocation 10 draft-zhang-coordinate-based-ipv6-multicast-00 12 Abstract 14 This specification defines an extension to the multicast addressing 15 architecture of the IP Version 6 protocol. The extension presented 16 in this document allows for coordinate-based allocation of IPv6 17 multicast addresses. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2 Specification of Requirements . . . . . . . . . . . . . . . . . 3 59 3. ND Option . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4 Multicast Address . . . . . . . . . . . . . . . . . . . . . . . 4 61 5 Address Lifetime . . . . . . . . . . . . . . . . . . . . . . . 6 62 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 8 Informative References . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1 Introduction 69 With the advancement of information technology and the advancement of 70 geographic information socialization, location information plays an 71 increasingly important role in social services and applications. This 72 document provides a way to dynamically allocate multicast addresses 73 based on geographic location information. Location-based multicasting 74 can be implemented. Currently, there are two general schemes for 75 identifying geographical locations, one is latitude and longitude, 76 the other is residential address, and the residential address is more 77 readable, but the coding of residential address is relatively poor. 78 This document uses latitude and longitude to identify location 79 information, and carry location information into an IPv6 multicast 80 address. 82 2 Specification of Requirements 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 3. ND Option 90 In [RFC6225], DHCPv6 adds the GeoLoc Option to carry latitude and 91 longitude information. You can use this option to obtain the latitude 92 and longitude information of the server. Currently, the latitude and 93 longitude information cannot be obtained in the case of stateless 94 address configuration. This document add options to the Neighbor 95 Discovery Router Advertisement message. The option is use to carry 96 sub-option. The GeoLoc Option is carried in the sub-option. The 97 GeoLoc Option format remains the same with which defined in 98 [RFC6225]. 100 The definition is as follows: 102 0 1 2 3 103 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | ND_OPTION_Extern(140) | OptLen | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | sub-option-type | suboption-len + 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Sub-option + 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Sub-option + 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Sub-option + 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 0 1 2 3 116 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | OPTION_GEOLOCATION(1) | OptLen | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | LatUnc | Latitude + 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Lat (cont'd) | LongUnc | Longitude + 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Longitude (cont'd) | AType | AltUnc | Altitude + 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Altitude (cont'd) |Ver| Res |Datum| 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 A detailed explanation of the format is given in [RFC6225]. 131 4 Multicast Address 133 Section 2.7 of [RFC4291] defines the following operational format of 134 IPv6 multicast addresses: 136 | 8 | 4 | 4 | 112 bits | 137 +-------+----+----+-----------------------------------------------+ 138 |11111111|flags|scop| group ID | 139 +--------+----+----+----------------------------------------------+ 141 flags is a set of 4 flags: 143 +-+-+-+-+ 144 |0|0|0|T| 145 +-+-+-+-+ 147 Unicast-Prefix-based Multicast Address updated by [RFC7371]: 149 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 150 +--------+----+----+----+----+--------+----------------+----------+ 151 |11111111|ff1 |scop|ff2 |rsvd| plen | network prefix | group ID | 152 +--------+----+----+----+----+--------+----------------+----------+ 153 ff1 (flag field 1) is a set of 4 flags: 155 +-+-+-+-+ 156 |0|0|P|T| 157 +-+-+-+-+ 159 Embedding the Address of the RP in the Multicast Address updated 160 by [RFC7371]: 162 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 163 +--------+----+----+----+----+----+----------------+----------+ 164 |11111111|ff1 |scop|ff2 |RIID|plen| network prefix | group ID | 165 +--------+----+----+----+----+----+----------------+----------+ 167 ff1 is a set of four flags: 169 +-+-+-+-+ 170 |0|R|P|T| 171 +-+-+-+-+ 173 This document introduces a new format that incorporates geographic 174 coordinate information in the multicast address: 175 | 8 | 4 | 4 | 98 | 14 | 176 +--------+----+----+--------------------------------+---------------+ 177 |11111111|flgs|scop| geographic coordinate |group ID | 178 +--------+----+----+--------------------------------+---------------+ 180 The geographic coordinate is the value of Latitude, Longitude, and 181 Altitude, including 34bit longitude, 34bit latitude, and 30bit 182 height. 184 flags is a set of 4 flags: 185 +-+-+-+-+ 186 |G|R|P|T| 187 +-+-+-+-+ 189 If G= 0 indicates a multicast address that is not assigned 190 based on geographic coordinate. This indicates a multicast 191 address as defined in [RFC4291]. 193 If G = 1 indicates a multicast address that is assigned based 194 on geographic coordinate. 196 If G = 1, T MUST be set to 1, otherwise the setting of the T 197 bit is defined in [RFC4291]. 199 Group ID is in the range of 1 to 0x3FFF.The Group ID is 200 configurable. 202 The geographic coordinate based dynamic multicast function are 203 configurable. Server can specify whether client should use 204 stateful(DHCPv6) and/or autonomous (stateless) address configuration. 205 When the DHCPv6 address allocation mode is adopted, the client sends 206 the OPTION_GEOLOCATION option through the OPTION_ORO defined in 207 RFC8415 to request the server to send the location information. After 208 receiving the location option information of the server, the client 209 generates an IPv6 multicast address according to the geographic 210 coordinate information. When the stateless address is automatically 211 allocated,the Neighbor Discovery Router Advertisement message carries 212 the location information through the OPTION_GEOLOCATION option 213 defined in this document. 215 5 Address Lifetime 217 The lifetime of a geographic coordinate based multicast address 218 SHOULD NOT exceed the Valid Lifetime of the delegated address. In 219 stateless address configuration the lifetime SHOULD NOT exceed the 220 Valid Lifetime field in the Prefix Information option,corresponding 221 to the unicast prefix being used, contained in the Neighbor Discovery 222 Router Advertisement message [RFC4861]. In stateful (DHCPv6) address 223 configuration the lifetime SHOULD NOT exceed the Valid Lifetime of an 224 address or delegated prefix[RFC8415]. 226 6 Security Considerations 228 Since there is no privacy protection for DHCPv6 and ND RA messages, 229 an eavesdropper who can monitor the link between the server and 230 requesting client can discover this OPTION_GEOLOCATION. 232 To minimize the unintended exposure of location information, the MD5- 233 keyed hash algorithm can be supported.While the MD5 digest is not 234 correct the message MUST be dropped. 236 0 1 2 3 237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | OPTION_LOCATIONMD5(145) | OptLen | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | key-id | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | MD5 + 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | MD5 + 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | MD5 + 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | MD5 | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 7 IANA Considerations 254 This document does not include an IANA request. 256 8 Informative References 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 [RFC8415] T. Mrugalski,M. Siodelski, B. Volz,A. Yourtchenko, 264 M. Richardson,S. Jiang,T. Lemon and T. Winters, 265 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 266 RFC8415, DOI 10.17487/RFC8415, November 2018, 267 . 269 [RFC4291] R. Hinden and S. Deering, "IP Version 6 Addressing 270 Architecture", RFC 4291, DOI 10.17487/RFC4291, 271 February 2006, 272 . 280 [RFC4861] T. Narten, E. Nordmark,W. Simpson and H.Soliman,"Neighbor 281 Discovery for IP Version 6 (IPv6)", RFC 4861, September 282 2007 284 [RFC7371] M. Boucadair, S. Venaas,,"Updates to the IPv6 Multicast 285 Addressing Architecture", RFC 7371, 286 September 2014 288 Authors' Addresses 290 Haihong Zhang 291 H3c Corporation 292 Beijing 293 P.R.China 295 Email: zhanghaihong.04355@h3c.com 297 Lin Luo 298 H3c Corporation 299 Hangzhou 300 P.R.China 302 Email: extrall@h3c.com 304 Qianli Zhang 305 Tsinghua University 306 Beijing 307 P.R.China 309 Email: zhang@cernet.edu.cn