Separation Protocol of Locator and Identifier Towards IPv6
draft-yu-v6ops-split6-01
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | haisheng yu | ||
| Last updated | 2021-12-22 | ||
| Stream | (None) | ||
| Formats | plain text html xml htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
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]