Internet DRAFT - draft-zhang-6man-ipv6-geoiid
draft-zhang-6man-ipv6-geoiid
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-01
Abstract
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
Zhang, et al. Expires March 27, 2020 [Page 1]
INTERNET DRAFT IPv6 geoiid September 2019
document authors. All rights reserved.
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
Zhang, et al. Expires March 27, 2020 [Page 3]
INTERNET DRAFT IPv6 geoiid September 2019
longitude code.
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 Considerations
This 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' Addresses
Pei 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]
