IPv6 maintenance Working Group (6man) Pei Zhang
INTERNET-DRAFT Beijing University of Posts and Telecommunications
Intended Status: Standards Track Qianli Zhang
Expires: March 27, 2020 Tsinghua University
Dandan Li
Beijing University of Posts and Telecommunications
Yan Ma
Beijing University of Posts and Telecommunications
Kun Xie
Beijing University of Posts and Telecommunications
September 24, 2019
An IPv6 stateless interface identifier generation method based on geographic location coding draft-zhang-6man-ipv6-geoiid-01Abstract
This document describes how to generate a stateless IPv6 host interface identifier based on host geographic location information. This method can guarantee the uniqueness and stability of the address generated within a certain geographical range. The method is similar to mechanism introduced in RFC 7217, but remains stable within an adjustable geographical area.
Status of this Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress".
This Internet-Draft will expire on March 27, 2020.
Copyright and License Notice
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Zhang, et al. Expires March 27, 2020 [Page 1]
INTERNET DRAFT IPv6 geoiid September 2019
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Algorithm Specification . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Zhang, et al. Expires March 27, 2020 [Page 2]
INTERNET DRAFT IPv6 geoiid September 2019 1. Introduction[RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for IPv6 [RFC8200], "stable" addresses would not change in the same network defined by a network prefix advertised by a local router. There are various IPv6 Interface Identifier (IID) generating schemes like EUI-64 [RFC4291], Cryptographically Generated Addresses (CGAs) [RFC3972] and Semantically Opaque Interface Identifiers [RFC7217]. [RFC8064] recommends using the mechanism specified in RFC 7217 to generate stable IPv6 Interface Identifier.
In some situations, it is desirable to generate stable IID in a specific geographical area, which is usually larger than a network defined by one network prefix. For example, multihomed site may configure the same IID with different prefixes to simplify network management. An organization may also hope clients have the same IID within a specific geographical area even if network prefix is different.
This document specifies a method to generate Interface Identifiers that are stable for each network interface within a specific geographical area, while still remain semantically opaque: like scheme proposed in RFC 7217, it is infeasible to extract geographical information from IIDs generated by this scheme.
2. Algorithm Specification
The generation scheme is similar to that proposed in RFC 7217, the random (but stable) identifier is generated with the expression: RID = F(Geo_Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key).Geo_Prefix: Geo_Prefix is the geographic identifier of the specific area, it can be formed from several possible approaches:
1)Latitude, longitude encoded prefix string. The basic mechanism is to interleave the WGS-84 latitude and longitude. Interleaving is a common technique to encode a geographic location. The number of bits is configured by the administrator to represent different area.
For longitude, the first bit is the sign bit. And the left side of the decimal point is directly converted to 8-bit binary code. The right side of the decimal point is generated according to the ANSI/IEEE Std 754-1985 standard. Then the binary corresponding to integer part and the decimal part are joined from upper bit to lower bit. The sign bit, the binary representation of the integer bit, and the binary representation of the decimal place are joined to form the longitude code.
Zhang, et al. Expires March 27, 2020 [Page 3]
INTERNET DRAFT IPv6 geoiid September 2019
For latitude, the first bit is the sign bit. The left side of the decimal point is directly converted to a seven-bit binary code. And the right side of the decimal point is generated with the same step. Then the binary corresponding to integer part and the decimal part are joined from upper bit to lower bit. The sign bit, the binary representation of the integer bit, and the binary representation of the decimal place are joined to form the latitude code.Latitude and longitude binary codes are interleaved to form the final 2n-bit position code. The longitude code is placed in odd digits and the latitude code is placed in even digits. Or the longitude code is placed in even digits and the latitude code is placed in odd digits. n is an adjustable parameter. Different n represents different accuracy to cover different geographic ranges.
In addition to longitude and latitude, it is also feasible to add height information together for encoding. For height, the encoding method is the same as the latitude and longitude encoding method. In the end, the binary codes of latitude, longitude and altitude are interleaved to form the final position code.
2)Geographical area specific text. The geographical area specific text identifies the geographical area in which the organization network is located. This name is consistent across this geographic area, and the organization guarantees that different geographic regions have different names.A geographical area specific text may be a lexical name of this geographical area, or just an alias. The geographical area specific text can be configured by the organization administrator.
The other processes of this scenario are essentially the same as those defined in RFC 7217. In this way, it is possible to implement the same interface identifiers on hosts with multiple interfaces or in an organization, even if the prefixes are different.
Zhang, et al. Expires March 27, 2020 [Page 4]
INTERNET DRAFT IPv6 geoiid September 2019 3. Security ConsiderationsThis document specifies an algorithm for generating Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), The scheme is similar to scheme defined in RFC 7217. While there may be concerns about geographic location tracking among multiple network, there is nothing inherent in this address format that would raise any more security considerations than any other global addressing format. If geographic location privacy were an issue, it would be wise to avoid this mechanism in favor of geographic location independent mechanisms.
4. IANA Considerations
This document does not include an IANA request.
5. Normative References
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017.
Zhang, et al. Expires March 27, 2020 [Page 5]
INTERNET DRAFT IPv6 geoiid September 2019
Authors' AddressesPei Zhang Beijing University of Posts and Telecommunications Beijing, 100876 P.R.China
Phone: +86-010 6119 8159 EMail: zhangpei@bupt.edu.cn
Qianli Zhang Tsinghua University Beijing, 100086 P.R.China
EMail: zhang@cernet.edu.cn
Dandan Li Beijing University of Posts and Telecommunications Beijing, 100876 P.R.China
EMail: dandl@bupt.edu.cn
Yan Ma Beijing University of Posts and Telecommunications Beijing, 100876 P.R.China
EMail: mayan@bupt.edu.cn
Kun Xie Beijing University of Posts and Telecommunications Beijing, 100876 P.R.China
EMail: pat@bupt.edu.cn
Zhang, et al. Expires March 27, 2020 [Page 6]
