idnits 2.17.1 draft-zhang-6man-ipv6-geoiid-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 24, 2019) is 1676 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) Pei Zhang 3 INTERNET-DRAFT Beijing University of Posts and Telecommunications 4 Intended Status: Standards Track Qianli Zhang 5 Expires: March 27, 2020 Tsinghua University 6 Dandan Li 7 Beijing University of Posts and Telecommunications 8 Yan Ma 9 Beijing University of Posts and Telecommunications 10 Kun Xie 11 Beijing University of Posts and Telecommunications 12 September 24, 2019 14 An IPv6 stateless interface identifier generation method 15 based on geographic location coding 16 draft-zhang-6man-ipv6-geoiid-01 18 Abstract 20 This document describes how to generate a stateless IPv6 host 21 interface identifier based on host geographic location information. 22 This method can guarantee the uniqueness and stability of the address 23 generated within a certain geographical range. The method is similar 24 to mechanism introduced in RFC 7217, but remains stable within an 25 adjustable geographical area. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute working 34 documents as Internet-Drafts. The list of current Internet-Drafts is 35 at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress". 42 This Internet-Draft will expire on March 27, 2020. 44 Copyright and License Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Algorithm Specification . . . . . . . . . . . . . . . . . . . 3 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 5. Normative References . . . . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for 71 IPv6 [RFC8200], "stable" addresses would not change in the same 72 network defined by a network prefix advertised by a local router. 73 There are various IPv6 Interface Identifier (IID) generating schemes 74 like EUI-64 [RFC4291], Cryptographically Generated Addresses (CGAs) 75 [RFC3972] and Semantically Opaque Interface Identifiers [RFC7217]. 76 [RFC8064] recommends using the mechanism specified in RFC 7217 to 77 generate stable IPv6 Interface Identifier. 79 In some situations, it is desirable to generate stable IID in a 80 specific geographical area, which is usually larger than a network 81 defined by one network prefix. For example, multihomed site may 82 configure the same IID with different prefixes to simplify network 83 management. An organization may also hope clients have the same IID 84 within a specific geographical area even if network prefix is 85 different. 87 This document specifies a method to generate Interface Identifiers 88 that are stable for each network interface within a specific 89 geographical area, while still remain semantically opaque: like 90 scheme proposed in RFC 7217, it is infeasible to extract geographical 91 information from IIDs generated by this scheme. 93 2. Algorithm Specification 95 The generation scheme is similar to that proposed in RFC 7217, the 96 random (but stable) identifier is generated with the expression: RID 97 = F(Geo_Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key). 99 Geo_Prefix: Geo_Prefix is the geographic identifier of the specific 100 area, it can be formed from several possible approaches: 102 1)Latitude, longitude encoded prefix string. The basic mechanism is 103 to interleave the WGS-84 latitude and longitude. Interleaving is a 104 common technique to encode a geographic location. The number of bits 105 is configured by the administrator to represent different area. 107 For longitude, the first bit is the sign bit. And the left side of 108 the decimal point is directly converted to 8-bit binary code. The 109 right side of the decimal point is generated according to the 110 ANSI/IEEE Std 754-1985 standard. Then the binary corresponding to 111 integer part and the decimal part are joined from upper bit to lower 112 bit. The sign bit, the binary representation of the integer bit, and 113 the binary representation of the decimal place are joined to form the 114 longitude code. 116 For latitude, the first bit is the sign bit. The left side of the 117 decimal point is directly converted to a seven-bit binary code. And 118 the right side of the decimal point is generated with the same step. 119 Then the binary corresponding to integer part and the decimal part 120 are joined from upper bit to lower bit. The sign bit, the binary 121 representation of the integer bit, and the binary representation of 122 the decimal place are joined to form the latitude code. 124 Latitude and longitude binary codes are interleaved to form the final 125 2n-bit position code. The longitude code is placed in odd digits and 126 the latitude code is placed in even digits. Or the longitude code is 127 placed in even digits and the latitude code is placed in odd digits. 128 n is an adjustable parameter. Different n represents different 129 accuracy to cover different geographic ranges. 131 In addition to longitude and latitude, it is also feasible to add 132 height information together for encoding. For height, the encoding 133 method is the same as the latitude and longitude encoding method. In 134 the end, the binary codes of latitude, longitude and altitude are 135 interleaved to form the final position code. 137 2)Geographical area specific text. The geographical area specific 138 text identifies the geographical area in which the organization 139 network is located. This name is consistent across this geographic 140 area, and the organization guarantees that different geographic 141 regions have different names.A geographical area specific text may be 142 a lexical name of this geographical area, or just an alias. The 143 geographical area specific text can be configured by the organization 144 administrator. 146 The other processes of this scenario are essentially the same as 147 those defined in RFC 7217. In this way, it is possible to implement 148 the same interface identifiers on hosts with multiple interfaces or 149 in an organization, even if the prefixes are different. 151 3. Security Considerations 153 This document specifies an algorithm for generating Interface 154 Identifiers to be used with IPv6 Stateless Address Autoconfiguration 155 (SLAAC), The scheme is similar to scheme defined in RFC 7217. While 156 there may be concerns about geographic location tracking among 157 multiple network, there is nothing inherent in this address format 158 that would raise any more security considerations than any other 159 global addressing format. If geographic location privacy were an 160 issue, it would be wise to avoid this mechanism in favor of 161 geographic location independent mechanisms. 163 4. IANA Considerations 165 This document does not include an IANA request. 167 5. Normative References 169 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 170 RFC 3972, March 2005. 172 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 173 Architecture", RFC 4291, February 2006. 175 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 176 Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 177 2007. 179 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 180 Interface Identifiers with IPv6 Stateless Address Autoconfiguration 181 (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014. 183 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 184 "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 185 10.17487/RFC8064, February 2017. 187 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 188 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 189 2017. 191 Authors' Addresses 193 Pei Zhang 194 Beijing University of Posts and Telecommunications 195 Beijing, 100876 196 P.R.China 198 Phone: +86-010 6119 8159 199 EMail: zhangpei@bupt.edu.cn 201 Qianli Zhang 202 Tsinghua University 203 Beijing, 100086 204 P.R.China 206 EMail: zhang@cernet.edu.cn 208 Dandan Li 209 Beijing University of Posts and Telecommunications 210 Beijing, 100876 211 P.R.China 213 EMail: dandl@bupt.edu.cn 215 Yan Ma 216 Beijing University of Posts and Telecommunications 217 Beijing, 100876 218 P.R.China 220 EMail: mayan@bupt.edu.cn 222 Kun Xie 223 Beijing University of Posts and Telecommunications 224 Beijing, 100876 225 P.R.China 227 EMail: pat@bupt.edu.cn