Separation Protocol of Locator and Identifier Towards IPv6
draft-yu-v6ops-split6-01

Network Working Group                                              H. Yu
Internet-Draft                                         Guangzhou Genlian
Intended status: Informational                          21 December 2021
Expires: 24 June 2022

       Separation Protocol of Locator and Identifier Towards IPv6
                        draft-yu-v6ops-split6-01

Abstract

   In the current TCP/IP architecture, the IPv6 address has a dual
   meaning in semantics.  It not only represents the topological
   location of the network node, but also the identity of the node,
   which is usually referred to as the semantic overload problem of the
   IP address.  The semantically overloaded IP address represents the
   topological position of the network, and the topological position of
   the network generally does not move, so the device entering the new
   network environment needs to replace the new identity IP to adapt to
   the change of the topological position.  The semantic overload of IP
   addresses is not conducive to supporting mobility and user identity
   authentication, resulting in tight storage space for routing
   equipment, lack of unified communication identification for network
   equipment, and difficulties in network traceability and management.
   In order to solve the problem of IP address semantic overload, this
   project focuses on the separation technology SPLIT6 of IP address
   identity and location.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] [RFC8174]
   when, and only when, they appear in all capitals, as shown here.

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 https://datatracker.ietf.org/drafts/current/.

Yu                        Expires 24 June 2022                  [Page 1]
Internet-Draft                   SPLIT6                    December 2021

   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 24 June 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IPv6 address semantics problem  . . . . . . . . . . . . . . .   3
   3.  exist network problem . . . . . . . . . . . . . . . . . . . .   3
   4.  possible solution . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In the current Internet architecture, the IPv6 address carries too
   much semantics.  The network layer protocol uses the IPv6 address as
   the location identifier of the user terminal, and the transport layer
   protocol uses the IPv6 address as the identity identifier of the user
   terminal.  This dual identity of the IPv6 address cannot satisfy the
   Internet's increasing mobility and security requirements.

   In order to solve these problems caused by the semantic overload of
   IPv6 addresses, separating the location information and identity
   information of IPv6 addresses has become an important research
   direction.

Yu                        Expires 24 June 2022                  [Page 2]
Internet-Draft                   SPLIT6                    December 2021

2.  IPv6 address semantics problem

   In the current TCP/IP architecture, the IPv6 address has a dual
   meaning in semantics at the same time.  It not only represents the
   topological location of the network node, but also the identity of
   the node, which is usually referred to as IP address semantic
   overload.  The semantically overloaded IP address represents the
   topological location, and the topological location cannot be moved,
   so the IP address representing the identity of the node cannot move
   with the movement of the user or device.  The equipment entering the
   new network environment needs to be replaced with a new identity IP
   to adapt to the change of topological location.  The semantic
   overload problem of IP addresses is not conducive to supporting
   mobility, affecting the scalability of core routing, reducing the
   effectiveness of existing security mechanisms, and restricting the
   development of several new technologies.  Due to the semantic
   overload problem of IP addresses, the following problems exist in
   TCP/IP in actual operation: The storage space of routing equipment is
   tight.  In order to improve and ensure the performance of the
   Internet, the routing table entries of the routing devices in the
   Internet should not be too many.  If a large number of IP address
   prefixes that have not been aggregated are advertised to the core
   route, it will cause the expansion of the core routing table entry
   DFZ (default-free zone), the increase in the frequency of route
   updates and the increase in communication volume, and the slower
   route convergence, which will cause serious problems.  Affect the
   performance and scalability of routing.

3.  exist network problem

   The network equipment lacks a unified communication identification.
   With the development of IOT (Internet Of Things) in the current
   Internet, the number of devices connected to the network has
   increased exponentially.  These devices need to communicate with
   other devices, so a unique communication identifier that can
   represent this device must have.  Currently, the industry does not
   agree to use IPv6 address as a universal communication identifier for
   devices.  There are two reasons.  One is because IP addresses have
   dual meanings.  As the network environment changes, the device IP
   address will also change.  Therefore, the difference between the
   device and the IPv6 address A one-to-one correspondence cannot be
   established between them; the second reason is that considering the
   performance and security of IOT devices, IOT devices are generally
   simple in design and only use the physical layer, link layer, and
   network layer of the network instead of the transport layer.  And
   application layer to reduce overhead.  Therefore, the IP address is
   generally used to identify the device, but many IOT devices are
   highly mobile.  How to ensure that the IOT device can still use a

Yu                        Expires 24 June 2022                  [Page 3]
Internet-Draft                   SPLIT6                    December 2021

   fixed IP address to identify it when it is moving is an important
   problem that needs to be solved.  In view of the above problems, if
   the coupling problem between the identification location and the
   identification identity can be solved, the development of IOT and the
   Internet of Things can be greatly promoted.

   Network security control is difficult.  The most important way of
   network security management and control is to trace the location and
   identity information of the IP address of the initiator of the
   network behavior.  However, in the current TCP/IP architecture, the
   IPv6 address has a dual meaning, which is not only fixed network
   location information, but also unbound identity information.  It is
   not possible to locate a specific device through the IP address, and
   then locate a certain person.  Because with the switching of the
   network environment, the same IP address may correspond to different
   users and different devices, and the devices of the same user will
   also be assigned to different IP addresses as the network switches.
   All these have caused great troubles to the supervision of network
   security.  Because the current network is insecure, an important
   reason for frequent network attacks is that the attacker's address
   cannot be traced to the source or it is difficult to trace the
   source.  If each user can be assigned a fixed identity-IPv6 address
   in the network, then network attackers will have nowhere to hide, and
   network supervision will become simple.  Therefore, IP semantic
   overload is the frequent occurrence of network attacks, and the
   source of the attack cannot be traced back to the root cause.

   User identity is difficult to authenticate.  Due to the dual meaning
   of IP, users cannot always log in to the network using a fixed IP
   address.  Because once the user switches the network environment, he
   needs to change his device's IP address and network configuration to
   log in to the network again.  The reason for this phenomenon is that
   the IP address assigned by the user has location attributes, so this
   IP address is bound to the network environment where it is located,
   and the IP address cannot move with the user's location.  Frequent
   switching of IP address and network environment will bring a lot of
   inconvenience to users.  For example, the ongoing network conference
   will be interrupted, the video being watched will be suspended, and
   the sending and receiving of emails will need to be re-authenticated
   with the IP address.  The mobile performance of the device is poor.
   In the current TCP/IP architecture, because the IPv6 address has a
   dual meaning, it represents the network topology location of the
   device, and it is also the identity of the device.  This leads to
   poor mobility of the device, and a device carrying a specific IP
   address cannot log in to the network after switching to another
   network environment.  These devices need to reconfigure the network
   and change the IP address to log in to the network again.  In the
   current Internet architecture, the IP address carries too much

Yu                        Expires 24 June 2022                  [Page 4]
Internet-Draft                   SPLIT6                    December 2021

   semantics.  The network layer protocol uses the IP address as the
   location identifier of the user terminal, and the transport layer
   protocol uses the IP address as the identity identifier of the user
   terminal.  This double identity of the IP address cannot Meet the
   increasing mobility and security needs of the Internet.

4.  possible solution

   In order to solve these problems caused by the semantic overload of
   IP addresses, it has become an urgent need for academia and industry
   to separate the location information and identity information of the
   IP address.  In recent years, countries around the world have
   successively initiated a number of research projects on the
   separation of IP address location information and identity
   information.  The MobilityFirst[1] project started in 2010 and was
   funded by the Future Internet Architecture (FIA) program of the
   National Science Foundation.  The first phase of the FIA project
   started in 2010-14 and produced a new mobility-centric architecture
   called MobilityFirst (MF), and a prototype implementation of the
   protocol stack.  IETF (Internet Engineering Task Force) [2]
   established a corresponding working group to study the separation of
   identity and location identification.  Among them, the HIP working
   group advocated by Ericsson mainly studied the host identity protocol
   HIP (Host Identity Protocol), and proposed rfc7401[3] and rfc8002[4].
   The Shim6 working group advocated by Sun company mainly researched on
   the IPv6 Multihoming Shim Protocol for IPv6 (Multihoming Shim
   Protocol for IPv6) and proposed RFC5533[5].  The RRG (Routing
   Research Group) working group advocated by Cisco mainly researches
   the Locator/Identifier Separation Protocl (Locator/Identifier
   Separation Protocl), and proposes RFC6830[6] and RFC8113[7].  In
   addition, there are TIDR (Tunneled Inter-Domain Routing) [8] and IVI
   [9] programs.  In these researches on network systems, it is
   generally believed that the semantic overload of IP addresses has
   affected the development of network system structures.  Therefore,
   breaking the semantic overload of IP addresses and establishing a
   network that separates location and identity has become an important
   issue to be solved in the construction of next-generation IP
   networks.

5.  Security Considerations

6.  IANA Considerations

   This document does not include an IANA request.

Yu                        Expires 24 June 2022                  [Page 5]
Internet-Draft                   SPLIT6                    December 2021

7.  Acknowledgements

   The authors would like to acknowledge XXX for their valuable review
   and comments.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <https://www.rfc-editor.org/info/rfc2460>.

Author's Address

   Haisheng Yu
   Guangzhou Genlian
   Beijing
   China

   Email: hsyu@biigroup.cn

Yu                        Expires 24 June 2022                  [Page 6]