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]