idnits 2.17.1 draft-yu-v6ops-split6-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 29 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Unrecognized Status in 'Intended status: InformationalGuangzhou Root Chain International Network Research Institute Co., Ltd.', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (21 December 2021) is 828 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5533' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'RFC7401' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'RFC8002' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'RFC8113' is defined on line 354, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC6052' is defined on line 371, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 8113 (Obsoleted by RFC 9304) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Yu 3 Internet-Draft H. Zhang 4 Intended status: InformationalGuangzhou Root Chain International Network Research Institute Co., Ltd. 5 Expires: 24 June 2022 21 December 2021 7 Separation Protocol of Locator and Identifier Towards IPv6 8 draft-yu-v6ops-split6-02 10 Abstract 12 In the current TCP/IP architecture, the IPv6 address has a dual 13 meaning in semantics. It not only represents the topological 14 location of the network node, but also the identity of the node, 15 which is usually referred to as the semantic overload problem of the 16 IP address. The semantically overloaded IP address represents the 17 topological position of the network, and the topological position of 18 the network generally does not move, so the device entering the new 19 network environment needs to replace the new identity IP to adapt to 20 the change of the topological position. The semantic overload of IP 21 addresses is not conducive to supporting mobility and user identity 22 authentication, resulting in tight storage space for routing 23 equipment, lack of unified communication identification for network 24 equipment, and difficulties in network traceability and management. 25 In order to solve the problem of IP address semantic overload, this 26 draft focuses on the separation technology SPLIT6 (Separation 27 Protocol of Locator and Identifier Towards IPv6) of IP address 28 identity and location. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in [RFC2119] [RFC8174] 35 when, and only when, they appear in all capitals, as shown here. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 24 June 2022. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Revised BSD License text as 65 described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Revised BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. IPv6 address semantics problem . . . . . . . . . . . . . . . 3 72 3. exist network problem . . . . . . . . . . . . . . . . . . . . 3 73 4. research status . . . . . . . . . . . . . . . . . . . . . . . 5 74 5. SPLIT6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 6. SPLIT6 Rules . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 81 10.2. Informative References . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 84 1. Introduction 86 In the current Internet architecture, the IPv6 address carries too 87 much semantics. The network layer protocol uses the IPv6 address as 88 the location identifier of the user terminal, and the transport layer 89 protocol uses the IPv6 address as the identity identifier of the user 90 terminal. This dual identity of the IPv6 address cannot satisfy the 91 Internet's increasing mobility and security requirements. 93 In order to solve these problems caused by the semantic overload of 94 IPv6 addresses, separating the location information and identity 95 information of IPv6 addresses has become an important research 96 direction. 98 2. IPv6 address semantics problem 100 In the current TCP/IP architecture, the IPv6 address has a dual 101 meaning in semantics at the same time. It not only represents the 102 topological location of the network node, but also the identity of 103 the node, which is usually referred to as IP address semantic 104 overload. The semantically overloaded IP address represents the 105 topological location, and the topological location cannot be moved, 106 so the IP address representing the identity of the node cannot move 107 with the movement of the user or device. The equipment entering the 108 new network environment needs to be replaced with a new identity IP 109 to adapt to the change of topological location. The semantic 110 overload problem of IP addresses is not conducive to supporting 111 mobility, affecting the scalability of core routing, reducing the 112 effectiveness of existing security mechanisms, and restricting the 113 development of several new technologies. 115 3. exist network problem 117 Due to the semantic overload problem of IP addresses, the following 118 problems exist in TCP/IP in actual operation: 120 The storage space of routing equipment is tight. In order to improve 121 and ensure the performance of the Internet, the routing table entries 122 of the routing devices in the Internet should not be too many. If a 123 large number of IP address prefixes that have not been aggregated are 124 advertised to the core route, it will cause the expansion of the core 125 routing table entry DFZ (default-free zone), the increase in the 126 frequency of route updates and the increase in communication volume, 127 and the slower route convergence, which will cause serious problems. 128 Affect the performance and scalability of routing. 130 The network equipment lacks a unified communication identification. 131 With the development of IOT (Internet Of Things) in the current 132 Internet, the number of devices connected to the network has 133 increased exponentially. These devices need to communicate with 134 other devices, so a unique communication identifier that can 135 represent this device must have. Currently, the industry does not 136 agree to use IPv6 address as a universal communication identifier for 137 devices. There are two reasons. One is because IP addresses have 138 dual meanings. As the network environment changes, the device IP 139 address will also change. Therefore, the difference between the 140 device and the IPv6 address A one-to-one correspondence cannot be 141 established between them; the second reason is that considering the 142 performance and security of IOT devices, IOT devices are generally 143 simple in design and only use the physical layer, link layer, and 144 network layer of the network instead of the transport layer. And 145 application layer to reduce overhead. Therefore, the IP address is 146 generally used to identify the device, but many IOT devices are 147 highly mobile. How to ensure that the IOT device can still use a 148 fixed IP address to identify it when it is moving is an important 149 problem that needs to be solved. In view of the above problems, if 150 the coupling problem between the identification location and the 151 identification identity can be solved, the development of IOT and the 152 Internet of Things can be greatly promoted. 154 Network security control is difficult. The most important way of 155 network security management and control is to trace the location and 156 identity information of the IP address of the initiator of the 157 network behavior. However, in the current TCP/IP architecture, the 158 IPv6 address has a dual meaning, which is not only fixed network 159 location information, but also unbound identity information. It is 160 not possible to locate a specific device through the IP address, and 161 then locate a certain person. Because with the switching of the 162 network environment, the same IP address may correspond to different 163 users and different devices, and the devices of the same user will 164 also be assigned to different IP addresses as the network switches. 165 All these have caused great troubles to the supervision of network 166 security. Because the current network is insecure, an important 167 reason for frequent network attacks is that the attacker's address 168 cannot be traced to the source or it is difficult to trace the 169 source. If each user can be assigned a fixed identity-IPv6 address 170 in the network, then network attackers will have nowhere to hide, and 171 network supervision will become simple. Therefore, IP semantic 172 overload is the frequent occurrence of network attacks, and the 173 source of the attack cannot be traced back to the root cause. 175 User identity is difficult to authenticate. Due to the dual meaning 176 of IP, users cannot always log in to the network using a fixed IP 177 address. Because once the user switches the network environment, he 178 needs to change his device's IP address and network configuration to 179 log in to the network again. The reason for this phenomenon is that 180 the IP address assigned by the user has location attributes, so this 181 IP address is bound to the network environment where it is located, 182 and the IP address cannot move with the user's location. Frequent 183 switching of IP address and network environment will bring a lot of 184 inconvenience to users. For example, the ongoing network conference 185 will be interrupted, the video being watched will be suspended, and 186 the sending and receiving of emails will need to be re-authenticated 187 with the IP address. 189 The mobile performance of the device is poor. In the current TCP/IP 190 architecture, because the IPv6 address has a dual meaning, it 191 represents the network topology location of the device, and it is 192 also the identity of the device. This leads to poor mobility of the 193 device, and a device carrying a specific IP address cannot log in to 194 the network after switching to another network environment. These 195 devices need to reconfigure the network and change the IP address to 196 log in to the network again. 198 In the current Internet architecture, the IP address carries too much 199 semantics. The network layer protocol uses the IP address as the 200 location identifier of the user terminal, and the transport layer 201 protocol uses the IP address as the identity identifier of the user 202 terminal. This double identity of the IP address cannot Meet the 203 increasing mobility and security needs of the Internet. 205 4. research status 207 In order to solve these problems caused by the semantic overload of 208 IP addresses, it has become an urgent need for academia and industry 209 to separate the location information and identity information of the 210 IP address. In recent years, countries around the world have 211 successively initiated a number of research projects on the 212 separation of IP address location information and identity 213 information. The MobilityFirst project started in 2010 and was 214 funded by the Future Internet Architecture (FIA) program of the 215 National Science Foundation. The first phase of the FIA project 216 started in 2010-14 and produced a new mobility-centric architecture 217 called MobilityFirst (MF), and a prototype implementation of the 218 protocol stack. IETF established a corresponding working group to 219 study the separation of identity and location identification. Among 220 them, the HIP working group advocated by Ericsson mainly studied the 221 host identity protocol HIP (Host Identity Protocol), and proposed 222 rfc7401 and rfc8002. The Shim6 working group advocated by Sun 223 company mainly researched on the IPv6 Multihoming Shim Protocol for 224 IPv6 (Multihoming Shim Protocol for IPv6) and proposed RFC5533. The 225 RRG (Routing Research Group) working group advocated by Cisco mainly 226 researches the Locator/Identifier Separation Protocl (Locator/ 227 Identifier Separation Protocl), and proposes RFC6830 and RFC8113. In 228 addition, there are TIDR (Tunneled Inter-Domain Routing) and IVI 229 programs. In these researches on network systems, it is generally 230 believed that the semantic overload of IP addresses has affected the 231 development of network system structures. Therefore, breaking the 232 semantic overload of IP addresses and establishing a network that 233 separates location and identity has become an important issue to be 234 solved in the construction of next-generation IP networks. 236 5. SPLIT6 238 In view of the mobility requirements and semantic overload of IP 239 addresses, this draft uses the idea ofseparation of location and 240 identity to carry out research on network naming and addressing 241 architecture. We propose a new type of naming and addressing 242 architecture: SPLIT6 to meet node mobility requirements and establish 243 end-to-end secure transmission based on identity. Using SPLIT6 can 244 not destroy the aggregation of the original IP addresses, and at the 245 same time facilitate the supervision of IP addresses. 247 Under the TCP/IP architecture, the IP address confuses the functional 248 boundaries of Locator and Identifier. Locator is a PA (Provider 249 Allocated) address, which should be allocated according to the 250 topology of the network to ensure the aggregation characteristics of 251 the address and support global routing; Identifier is a PI (Provider 252 Independent) address, which is usually allocated according to the 253 organizational structure of the organization, and it is generally 254 difficult to aggregate. It cannot be routed globally. Therefore, 255 unless there is a breakthrough in flat identification routing, it is 256 difficult to use a unified address to achieve the above two 257 functions. 259 This draft proposes an architecture based on the separation of 260 network-based Locator and Identifier: SPLIT6. SPLIT6 distinguishes 261 the core network and the edge network. The core network uses the 262 Locator name space, and the edge network uses the Identifier name 263 space. The use of structured location identification in the core 264 network ensures the aggregation characteristics of the core routing 265 identification (Locator) and improves the scalability of the core 266 network. A fixed identifier (Identifier) in the edge network 267 represents a network node, and a communication session is established 268 based on the identifier. The identity is not restricted by the site 269 topology and can better support mobility. In addition, Identifier 270 can be expressed as a name space with a specific meaning without 271 restriction. 273 SPLIT6 needs to use a fixed network IP address to realize the roaming 274 function of computers across different network segments, and to 275 ensure that the network authority based on the network IP does not 276 change during the roaming process. Just like the mobile phone used 277 now. First of all, a proxy router needs to be deployed in each 278 network. Every local terminal device will be registered on this 279 proxy router (as if each mobile phone number is registered at the 280 home location), and the terminal device will get an IP address 281 belonging to this network. , All data packets can reach this terminal 282 device with the terminal IP address as the destination address. This 283 proxy router is called the Home Agent (HA). Secondly, a foreign 284 proxy server needs to be deployed. When a terminal device roams to a 285 foreign network, the terminal device needs to notify the home agent 286 and the agent router of the network where it is located. This agent 287 router is called a foreign agent (FA). A handshake will be 288 established between the home agent and the foreign agent (as if the 289 mobile phone is registered in the roaming place, and the roaming 290 network informs the home network of the mobile phone number). After 291 the handshake, the foreign agent assigns a Locator, which is the PA 292 address, to the terminal. In the communication process, the data 293 packet still uses the original address (Identifier, PI address) of 294 the terminal device as the destination address, and first reaches the 295 foreign agent. The foreign agent replaces the Identifier with the 296 Locator address for transmission according to the mapping table it 297 owns, and adds the Identifier to the TLV field of the hop-by-hop 298 option header for identification. 300 6. SPLIT6 Rules 302 SPLIT6 architecture shall follow the following two principles: 304 1.Identifier address should only be used in the identifier space, 305 without entering the locator space, unless: identifier address equals 306 naming address 308 2.Locator address is only used in the locator space and does not 309 enter the identifier space, unless: identifier address equals naming 310 address 312 Therefore, the end to end communication of SPLIT6 can be categorized 313 into following four conditions depend on whether the device has moved 314 or not. 316 7. Security Considerations 318 8. IANA Considerations 320 This document does not include an IANA request. 322 9. Acknowledgements 324 The authors would like to acknowledge XXX for their valuable review 325 and comments. 327 10. References 329 10.1. Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, 333 DOI 10.17487/RFC2119, March 1997, 334 . 336 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 337 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 338 June 2009, . 340 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 341 Locator/ID Separation Protocol (LISP)", RFC 6830, 342 DOI 10.17487/RFC6830, January 2013, 343 . 345 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 346 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 347 RFC 7401, DOI 10.17487/RFC7401, April 2015, 348 . 350 [RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol 351 Certificates", RFC 8002, DOI 10.17487/RFC8002, October 352 2016, . 354 [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation 355 Protocol (LISP): Shared Extension Message & IANA Registry 356 for Packet Type Allocations", RFC 8113, 357 DOI 10.17487/RFC8113, March 2017, 358 . 360 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 361 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 362 May 2017, . 364 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 365 (IPv6) Specification", STD 86, RFC 8200, 366 DOI 10.17487/RFC8200, July 2017, 367 . 369 10.2. Informative References 371 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 372 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 373 DOI 10.17487/RFC6052, October 2010, 374 . 376 Authors' Addresses 377 Haisheng Yu 378 Guangzhou Root Chain International Network Research Institute Co., Ltd. 379 Xiangjiang International Technology Innovation Center, 41 Jinlong Road, Nansha District, Guangzhou 380 Guangzhou 381 China 383 Email: hsyu@biigroup.cn 385 Hanzhuo Zhang 386 Guangzhou Root Chain International Network Research Institute Co., Ltd. 387 Xiangjiang International Technology Innovation Center, 41 Jinlong Road, Nansha District, Guangzhou 388 Guangzhou 389 China 391 Email: hzzhang@biigroup.cn