idnits 2.17.1 draft-song-ship-edge-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 : ---------------------------------------------------------------------------- No issues found here. 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. -- The document date (11 October 2021) is 928 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC7775' is defined on line 538, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Song 3 Internet-Draft Futurewei Technologies 4 Intended status: Experimental 11 October 2021 5 Expires: 14 April 2022 7 Short Hierarchical IP Addresses at Edge Networks 8 draft-song-ship-edge-02 10 Abstract 12 To mitigate the IPv6 header overhead in edge networks, this draft 13 proposes to use short hierarchical addresses excluding the network 14 prefix within edge networks. An edge network can be further 15 organized into a hierarchical architecture containing one or more 16 levels of networks. The border routers for each hierarchical level 17 are responsible for address augmenting and pruning when a packet 18 leaves or enter a lower level network. Specifically, the top-level 19 border routers convert the internal IP header to and from the 20 standard IPv6 header. This draft presents an incrementally 21 deployable scheme allowing packet header to be effectively compressed 22 in edge networks without affecting the network interoperability. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 28 "OPTIONAL" in this document are to be interpreted as described in BCP 29 14 [RFC2119][RFC8174] when, and only when, they appear in all 30 capitals, as shown here. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 14 April 2022. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Short Hierarchical Address in Edge Networks . . . . . . . . . 3 67 2.1. Edge Network Hierarchy . . . . . . . . . . . . . . . . . 3 68 2.2. Address Fields . . . . . . . . . . . . . . . . . . . . . 5 69 2.3. Router Roles and Function . . . . . . . . . . . . . . . . 6 70 3. Deployment and Interoperability Consideration . . . . . . . . 9 71 3.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 9 72 3.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 11 73 3.3. Using NAT for the edge network . . . . . . . . . . . . . 11 74 3.4. Extension Beyond IPv6 . . . . . . . . . . . . . . . . . . 12 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 7.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 Internet of Things (IoT) and 5G introduce to the Internet a huge 86 number of addressable entities (e.g., sensors, machines, vehicles, 87 and robots). The transition to IPv6 is inevitable. While the 88 128-bit address of IPv6 was considered large enough and future-proof, 89 the long IP addresses inflate the packet header size. 80% of a basic 90 IPv6 header is consumed by addresses. 92 In IoT networks, thing-to-thing communication through wireless 93 connections is dominant, which presents several distinct 94 characteristics. (1) The communication pattern is often frequent 95 short-message exchanges (e.g., industry robots and networked 96 vehicles). (2) The communication is usually energy sensitive (e.g., 97 battery-powered sensors). (3) The communication often requires low 98 latency (e.g., industry control). (4) The precious wireless channels 99 demand high bandwidth utilization (e.g., ZigBee, Bluetooth, Wi-Fi, 100 and 5G). These characteristics render a large header overhead 101 unfavorable and even prohibitive. 103 The address overhead also takes its toll on Data Center Networks 104 (DCN), especially when large scale containers are deployed, the east- 105 west traffic is dominant, and the prevailing communications are 106 comprised of short messages (e.g., key-value pairs) and conducted 107 through virtual switches. 109 In IoT and DCN, since most communications happen between adjacent and 110 related entities, it is a good practice to locally confine 111 communication, computing, and storage due to performance, efficiency, 112 and security considerations, as advocated by Edge Computing. Such a 113 communication pattern provides an opportunity to mitigate the IPv6 114 header overhead problem due to the long addresses. 116 When an IPv6 address block is allocated to an edge network, all the 117 entities in the edge network share the same address prefix. When 118 these entities communicate with each other, they can ignore the 119 common prefix. In fact, they don not even need to know the common 120 prefix. Only when they need to communicate with entities outside of 121 the edge network, the full addresses are needed. Even in this case, 122 the entities in the edge network still do not need to know the 123 prefix. It is sufficient for the gateway routers at the network 124 border to manipulate the addresses (i.e., augmenting or pruning the 125 address) to meet the addressing requirement. 127 Following this line of thought, an edge network can be further 128 partitioned into multiple hierarchical levels, which support flexible 129 sub-networking. The result is that an end entity needs to maintain 130 an even shorter address as its identifier. For communication 131 crossing network levels, the address manipulation is done at each 132 gateway router on the path recursively. 134 2. Short Hierarchical Address in Edge Networks 136 2.1. Edge Network Hierarchy 138 In this draft, we define an edge network as a stub network which does 139 not support traffic transit service. The stub network is assigned an 140 IPv6 address block. In this sense, a data center network in cloud 141 can also be considered as an edge network. An edge network usually 142 falls under a single network administration domain. 144 The address block assigned to an edge network is identified by a 145 prefix P with the length of L < 128 bits. The remaining S = 128-L 146 bits can be used to assign addresses to the entities in this network. 147 A key observation is: the entities in this network do not need to be 148 aware of P's length and value at all. We can further partition the 149 edge network into multiple hierarchical levels, making a tree 150 architecture. The root represents the entire edge network. Each 151 other node represents a lower level network occupying a sub address 152 space owned by its parent node. A leaf node represents a lowest 153 level network. We name the root level network the L_0 network. Its 154 children are all L_1 networks, and so on so forth. In other words, 155 the network level is the depth of the corresponding node in the tree. 157 The network hierarchy partitions the S-bit address into multiple 158 sections. Assume an entity is in an L_n network. The S-bit address 159 is partitioned into n+1 sections. The entity only needs to keep the 160 last section of the S-bit address as its ID. The gateway routers for 161 each level of network maintain one section of the S-bit address. 162 Specifically, the gateway routers of L_i (i>0) keep the i-th section 163 of the S-bit address, and the gateway routers of L_0 keep the 164 assigned IPv6 address block prefix P. 166 Figure 1 shows an edge network example, in which are three network 167 levels. The edge network A is assigned a 96-bit IPv6 address prefix 168 (2001:0db8:ac10:fe01::0001), which means it owns a 32-bit address 169 space. In this space, two L_1 networks are created: B with a 16-bit 170 prefix (0xaaaa) and C with a 24-bit prefix (0xcccccc). Note that the 171 prefixes at the same level must not overlap in order to guarantee 172 entities in the edge network are uniquely addressable. Network B 173 contains two entities x and y, and Network C contains one entity z. 174 In network B, an L_2 network C is further created with a 8-bit prefix 175 (0xbb). In this example, an entity in C or D (e.g., m and z) only 176 need to own a 8-bit address, an entity in B but not in D (e.g., x and 177 y) needs to own a 16-bit address, and an entity in A but not in B and 178 C needs to own a 32-bit address. In this way, each entity in A still 179 logically owns a unique IPv6 address (e.g., the IPv6 address of the 180 entity m in D with ID of 5 is 2001:0db8:ac10:fe01::0001:aaaa:bb05), 181 although the entity m is only aware of its local ID (0x05). 183 +------+ 184 | L0:A | 2001:0db8:ac10:fe01::0001/96 185 +-+--+-+ 186 | | 187 +------+ +-------+ 188 | | 189 +---+--+ +--+---+ 190 (x,y) | L1:B | aaaa/16 | L1:C | cccccc/24 191 +---+--+ +------+ 192 | (z) 193 +---+--+ 194 (m) | L2:D | bb/8 195 +------+ 197 Figure 1: A Hierarchical Edge Network Example 199 2.2. Address Fields 201 The edge networks adopting the short and variable size address scheme 202 need a new type of IP header, which is referred as IPvn in this 203 draft. Apart from the IP version, the major difference between IPvn 204 and IPv6 headers is the address fields. IPvn replaces IPv6's 128-bit 205 source address field and 128-bit destination address field with the 206 four fields shown in Figure 2. 208 +------------+------------+ 209 | SAL | DAL | 210 +------------+------------+ 211 | SA (variable length) | 212 +-------------------------+ 213 | DA (variable length) | 214 +-------------------------+ 216 Figure 2: IPvn Address Fields 218 The Source Address Length (SAL) and the Destination Address Length 219 (DAL) fields have fixed length, while the Source Address (SA) and the 220 Destination Address (DA) fields are of variable length. To simplify 221 the implementation, SA and DA are preferred to be byte-aligned. It 222 is possible to define the length of address in the unit of byte, 223 nibble, or bit. Each has its own pros and cons. The unit of byte 224 can help reduce the size of the SAL/DAL but results in coarse network 225 granularity which might be inefficient in address allocation. For 226 example, a 3-bit SAL/DAL is enough to encode 8 possible address 227 lengths (one to eight bytes) for networks. In this design, each 228 higher level network's address space expands 256 times. On the other 229 extreme, the unit of bit allows fine network granularity but requires 230 more space for SAL/DAL. For example, 6-bit SAL and DAL can support 231 an address length up to 64 bits (8 bytes) and each higher level 232 network is only twice larger. 234 With a few bits, it is also possible to design a more sophisticated 235 encoding scheme that supports variable address length steps and 236 adapts to the ideal network sizes at different levels. 238 Assuming SA and DA are 2 bytes each, and SAL and DAL are 4 bits each, 239 the address fields are only 5 bytes in total. Comparing to IPv6, the 240 size of the address fields is reduced by 84%. 242 2.3. Router Roles and Function 244 In the edge network hierarchy, each network has one or more Level 245 Gateway Routers (LGR) which are responsible for forwarding packets in 246 or out of this network. The LGRs are the only interface between a 247 network and its parent network. 249 A network can be in a single L2 domain, which means all the entities 250 in this network (excluding those in its child networks) and all the 251 network devices (including the LGRs to the parent network and the 252 child networks) are L2 reachable. A network can also be a pure L3 253 network in which no L2 device is allowed. Each entity in a network 254 is directly connected to either an LGR or some internal routers named 255 Intra-Level Router (ILR) which is solely responsible for packet 256 forwarding within the network. In this case, the entities need to 257 partially participate in the routing process (e.g., advertising its 258 address). 260 The scale of an intra-level network can be used to guide the L2/L3 261 selection. Small networks prefer the L2-based solution and large 262 networks prefer the L3-based solution. In the higher level networks 263 (e.g., closer to the top level network or the tree root), since the 264 number of entities is usually small, it is free to choose between L2 265 or L3-based solution. The leaf level networks are usually L2-based 266 for simplicity. 268 Unlike in IPv4 and IPv6 networks, the address related fields in IPvn 269 header can be modified by LGRs. An LGR of a network keeps a prefix 270 that can augment the SAs from this network to an address outside of 271 this network. If an LGR needs to forward an internal packet outside 272 (i.e., DAL > SAL), it augments the packet's SA and updates its SAL 273 accordingly. Reversely, if an LGR receives a packet from the parent 274 network destined for the child network for which it serves as a 275 gateway (i.e., the parent network prefix matches the DA's prefix), it 276 strips off the parent network prefix from the packet's DA and updates 277 its DAL accordingly. 279 In contrast, within an L3-based level network, ILRs do not modify the 280 address fields. An ILR can decide the packet forwarding direction by 281 examining the DAL. If DAL > SAL, the packet needs to be forwarded to 282 an LGR of this network; otherwise, the packet needs to be forwarded 283 within the current network, and possibly into a lower-level child 284 network. 286 An LGR of the top-level network (i.e., the L0 network) is special. 287 In addition to the address manipulation, it is also responsible for 288 converting the IPvn header to and from the standard IPv6 header to 289 support the Internet interoperability. We name such a router IP 290 Translator (IPT). 292 We use the edge network shown in Figure 1 to illustrate some packet 293 forwarding examples. The details for the involved entities are 294 summarized in Figure 3. In the IPvn packet header, we use 4 bits to 295 encode the address length. In particular, 0b0000 is used to indicate 296 the address is 16 bytes long (i.e., a complete IPv6 address). 298 +------+------+------+-----+-------+------------+ 299 |Entity| ID |Length|Level|Network| Prefix | 300 +------+------+------+-----+-------+------------+ 301 | x |0x0001| | | | | 302 +------+------|2bytes| 1 | B |0xaaaa/16 | 303 | y |0x0002| | | | | 304 +------+------+------+-----+-------+------------+ 305 | z |0x01 |1byte | 1 | C |0xcccccc/24 | 306 +------+------+------+-----+-------+------------+ 307 | m |0x08 |1byte | 2 | D |0xbb/8 | 308 +------+------+------+-----+-------+------------+ 310 Figure 3: Entity Address Configuration 312 The first example in Figure 4 shows how packets are forwarded from x 313 to y within the same network B. In this case, the source address and 314 destination address have the same length. The packets only pass 315 through an ILR which does not change the address fields. 317 +-----------------+ +-----------------+ +-----------------+ 318 | IPvn Header | | IPvn Header | | IPvn Header | 319 +--------+--------+ +--------+--------+ +--------+--------+ 320 |SAL:0x2 |DAL:0x2 | |SAL:0x2 |DAL:0x2 | |SAL:0x2 |DAL:0x2 | 321 +--------+--------+ +--------+--------+ +--------+--------+ 322 |SA: 0x0001 | |SA: 0x0001 | |SA: 0x0001 | 323 +-----------------+ +-----------------+ +-----------------+ 324 |DA: 0x0002 | |DA: 0x0002 | |DA: 0x0002 | 325 +-----------------+ +-----------------+ +-----------------+ 326 Entity x ------> ILR in B ------> Entity y 328 Figure 4: Forward within a network level in the edge 330 The second example in Figure 5 shows how packets are forwarded from x 331 in B to z in C. At LGR of B, the source address is augmented, and at 332 the LGR of C, the destination address is pruned. Since x and z's 333 nearest common ancestor network is A, so the packets never need to 334 leave network A, so A's prefix is oblivious throughout the 335 communication. 337 +---------------+ +---------------+ +---------------+ +---------------+ 338 | IPvn Header | | IPvn Header | | IPvn Header | | IPvn Header | 339 +-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+ 340 |SAL:0x2|DAL:0x4| |SAL:0x4|DAL:0x4| |SAL:0x4|DAL:0x1| |SAL:0x4|DAL:0x1| 341 +-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+ 342 |SA: 0x0001 | |SA: 0xaaaa0001 | |SA: 0xaaaa0001 | |SA: 0xaaaa0001 | 343 +---------------+ +---------------+ +---------------+ +---------------+ 344 |DA: 0xcccccc01 | |DA: 0xcccccc01 | |DA: 0x01 | |DA: 0x01 | 345 +---------------+ +---------------+ +---------------+ +---------------+ 346 Entity x -----> LGR of B -----> LGR of C -----> Entity z 348 Figure 5: Forward to another network in the edge 350 The last example in Figure 6 shows how packets are forwarded from x 351 in B to a host in IPv6 domain. In the IPT of A, the IPvn header is 352 converted to an IPv6 header. 354 +---------------+ +---------------+ +---------------+ +---------------+ 355 | IPvn Header | | IPvn Header | | IPv6 Header | | IPv6 Header | 356 +-------+-------+ +-------+-------+ +---------------+ +---------------+ 357 |SAL:0x2|DAL:0x0| |SAL:0x4|DAL:0x0| |SA: 2001:0db8 | |SA: 2001:0db8 | 358 +-------+-------+ +-------+-------+ | ac10:fe01: | | ac10:fe01: | 359 |SA: 0x0001 | |SA: 0xaaaa0001 | | 0000:0001: | | 0000:0001: | 360 +---------------+ +---------------+ | aaaa:0001 | | aaaa:0001 | 361 |DA: 2001:0db8: | |DA: 2001:0db8: | +---------------+ +---------------+ 362 | 85a3:0000: | | 85a3:0000: | |DA: 2001:0db8: | |DA: 2001:0db8: | 363 | 0000:8a2e: | | 0000:8a2e: | | 85a3:0000: | | 85a3:0000: | 364 | 0370:7334 | | 0370:7334 | | 0000:8a2e: | | 0000:8a2e: | 365 +---------------+ +---------------+ | 0370:7334 | | 0370:7334 | 366 +---------------+ +---------------+ 368 Entity x -----> LGR of B -----> IPT of A -----> Entity n 370 Figure 6: Forward out of the edge network 372 3. Deployment and Interoperability Consideration 374 3.1. Control Plane 376 Within the edge networks where IPvn is applied, all the control plane 377 functions and protocols need to be modified or redesigned due to the 378 hierarchical network architecture of IPvn. Fortunately, the updates 379 are often incremental and the results are usually simpler than their 380 counterparts in IPv4 and IPv6. We briefly discuss a few essential 381 protocols that enable the operation of IPvn. 383 DHCP: An entity can be manually configured or dynamically acquire 384 its address when booting up. Each network in the edge network 385 hierarchy may contain a Dynamic Host Configuration Protocol (DHCP) 386 server responsible for assigning addresses (i.e., IDs) to the 387 entities in the same network. The protocol is almost identical to 388 that for IPv4 and IPv6, except that the assigned address length is 389 adaptive to the allocated network size. 391 DNS: For an entity to acquire the address of a peer entity in order 392 to initiate a communication, Domain Name System (DNS) is the 393 prominent approach but with a new service model. Any network in 394 the hierarchy can provide name service. Each entity is configured 395 with the address of the closest DNS server on the path to the root 396 network. The hierarchical network architecture allows a scoped 397 domain name service. That is, a name registered in a network is 398 only valid in this network and its child networks. It is possible 399 that a same name is registered in two networks and one network is 400 the other's ancestor. Such name conflict is not a bug but a 401 feature for name reuse, which is transparent to the name query 402 process. In this case, the name resolved from the closer DNS 403 server is used. 405 Each network may contain a DNS server (the notation is only 406 logical. The actual implementation may follow the same 407 hierarchical and distributed architecture of today's DNS). Each 408 DNS server knows the nearest DNS server in a higher level network 409 and the nearest DNS servers in lower level networks. This 410 essentially organizes the DNS servers in the same tree structure 411 as the hierarchical network. Each named entity in a network is 412 registered with the DNS server that covers its scope, which is 413 basically a subtree. 415 We have several methods to populate the name to support the scoped 416 name queries, each with different storage and performance trade- 417 off: 1) register the name in all the DNS servers in its scope 418 (i.e., all the subtree nodes); 2) recursively register the name in 419 every parent DNS server until the scope root; and 3) register the 420 name only in the DNS server in its scope root. The address for a 421 name returned by a DNS server is on a "need-to-know" basis. In a 422 network, if the address's prefix matches the query's address 423 prefix, the prefix is removed. This can be easily done by the 424 original or the relay DNS servers. If a query cannot be resolved 425 by the DNS server in the L0 network, the query, after the IP 426 protocol translation is done, exits the IPvn domain and enters 427 into the IPv4/IPv6 domain to a public DNS server. When the 428 response comes back and enters the edge network, the result can be 429 cached by the DNS servers on the path. 431 ARP: In a L2-based network, the operation of Address Resolution 432 Protocol (ARP) or Neighbor Discovery Protocol (NDP) is almost 433 identical to that for IPv4 and IPv6. In an L2- based network, 434 each immediate entity should be configured with a default gateway 435 address to its parent network. If no default gateway is 436 configured, a network LGR should be configured as an ARP proxy to 437 respond to all internal ARP requests for addresses out of the 438 network. Similarly, the LGRs to any child network of this network 439 are also needed to be configured as ARP proxy to response all ARP 440 requests for addresses in that network. Due to the multi-homing 441 gateway routers, an ARP request may receive multiple responses. 442 It is up to the requester to determine which one to cache. 444 Routing Protocol: The entire edge network may belong to a single AS, 445 so the interior gateway routing protocols (IGP) such as OSPF and 446 IS-IS can be used. Other child networks in this network can be 447 considered OSPF stub areas or IS-IS levels. A simpler way is that 448 each network run an independent instance of OSPF or IS-IS. 450 Specially, an LGR at a network border runs two OSPF/IS-IS 451 instances: one for the upper-level network and the other for the 452 lower-level network. The hierarchical architecture solves the 453 routing protocol scalability issue, and simplifies the protocol 454 implementation by removing unnecessary features. The clean 455 routing scope helps to secure the infrastructure and troubleshoot 456 the networks. 458 3.2. Data Plane 460 IPvn Socket for End Entities: To enable IPvn as a new network layer 461 protocol in end entities, we need to add the protocol 462 implementation in the OS Kernel and allow applications to invoke 463 the socket API using the address family parameter AF_INETN. The 464 L4-L7 protocol stack and the application logic remains the same, 465 allowing direct communication between entities in IPvn domain and 466 in IPv4/IPv6 domain. 468 Forwarding Table Lookups in Networks: The short hierarchical address 469 simplifies the router forwarding table structure in L3-based 470 networks. A forwarding table only contains the addresses to local 471 entities and the prefixes to the child networks. Since there is 472 no nested prefixes, the Longest Prefix Matching (LPM) is not 473 necessary. The small number of unique prefix lengths allows the 474 prefixes to be grouped on lengths and each group to be implemented 475 as a hash table. A lookup can search all the hash tables in 476 parallel, and at most one table can result a positive match. This 477 design avoids the use of expensive TCAM or other complex trie- 478 based algorithms. 480 An LGR between an L_i network and an L_(i+1) network has two types 481 of interfaces: one faces the L_i network and the other faces the 482 L_(i+1) network. One LGR may serve more than one L_(i+1) network. 483 Hence, an LGR may contain multiple logical forwarding tables, with 484 each for a network. For a packet in LGR, once its target network 485 is determined and the address related fields are processed, the 486 proper forwarding table can be searched. 488 3.3. Using NAT for the edge network 490 To expand the address space of the edge network, the IPT of the edge 491 network can also support functions similar to NAT. In this case, the 492 edge network is assigned one or more public IPv4/IPv6 addresses. The 493 entities in IPvn domain use private addresses. The IPT maintains the 494 mapping table between the private address and public address. 496 3.4. Extension Beyond IPv6 498 Although the motivation of this draft is to support shorter address 499 (i.e., smaller L3 header overhead) in edge networks, it is worth 500 noting that the scheme allows the addresses to be extend to arbitrary 501 length, even longer than 128bits. In that case, the address space of 502 the IPvn network can be greater than that of IPv6 and the entire IPv6 503 network can be considered an edge network of the IPvn network. This 504 scenario should be considered when specifying the address fields of 505 IPvn. 507 4. Security Considerations 509 The addressing scheme and architecture allow a securer edge network. 510 The IPTs and LGRs naturally support the access control. 512 5. IANA Considerations 514 The proposal requires to use a new IP version and define a new IP 515 header which can be converted to/from an equivalent IPv6 header. 517 6. Acknowledgments 519 We acknowledge the technical contributions, suggestions and comments 520 from Yingzhe Qu, Zhaobo Zhang, James Guichard, Toerless Eckert, 521 Stewart Bryant, and Michael McBride. 523 7. References 525 7.1. Normative References 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, 529 DOI 10.17487/RFC2119, March 1997, 530 . 532 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 533 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 534 May 2017, . 536 7.2. Informative References 538 [RFC7775] Ginsberg, L., Litkowski, S., and S. Previdi, "IS-IS Route 539 Preference for Extended IP and IPv6 Reachability", 540 RFC 7775, DOI 10.17487/RFC7775, February 2016, 541 . 543 Author's Address 545 Haoyu Song 546 Futurewei Technologies 547 Santa Clara, 548 United States of America 550 Email: haoyu.song@futurewei.com