idnits 2.17.1 draft-dykim-6man-sid6-00.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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 3, 2018) is 2056 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'HIP' is mentioned on line 781, but not defined == Missing Reference: 'ILNP' is mentioned on line 785, but not defined == Missing Reference: 'LISP' is mentioned on line 790, but not defined == Missing Reference: 'SID6P' is mentioned on line 795, but not defined ** Obsolete normative reference: RFC 3315 (ref. 'DHCPv6') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (ref. 'SLAACPRIV') (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group DY Kim 3 Internet-Draft Independent 4 Intended status: Experimental September 3, 2018 5 Expires: March 7, 2019 7 Subnet ID Deprecation for IPv6 8 draft-dykim-6man-sid6-00 10 Abstract 12 Deprecation of the subnet ID in IPv6 networking is proposed; the 13 subnet ID is set to zero so that all nodes in a site carry the same 14 prefix. While the procedures for neighbor discovery and duplicate 15 address detection have to be changed, possible simplification gains 16 in IPv6 networking including that of intra-site host- and subnet- 17 mobility might be worth the modification. Site-external behaviors 18 don't change through this modification, enabling incremental 19 deployment of the proposal. Sites of manageable sizes for which 20 scalability is not much a critical issue might consider the mode of 21 operation proposed in this document. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 7, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. SID6 Construction . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 5 62 3.3. Duplicate Address Detection . . . . . . . . . . . . . . . 7 63 3.4. Interior Gateway Protocols . . . . . . . . . . . . . . . 8 64 3.5. Other Address-Related Protocols . . . . . . . . . . . . . 8 65 3.6. Generalization . . . . . . . . . . . . . . . . . . . . . 8 66 4. Consequencies . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.1. Recursive Networking . . . . . . . . . . . . . . . . . . 10 68 4.2. No Locator/ID Separation . . . . . . . . . . . . . . . . 10 69 4.3. Inherent Interior Mobility . . . . . . . . . . . . . . . 11 70 4.4. Faster Interior Mobility . . . . . . . . . . . . . . . . 11 71 4.5. Legacy Exterior Mobility . . . . . . . . . . . . . . . . 12 72 4.6. Legacy Migration and Multihoming . . . . . . . . . . . . 12 73 4.7. Usual Use of NPTv6 and ULA . . . . . . . . . . . . . . . 13 74 4.8. Incremental Deployability . . . . . . . . . . . . . . . . 13 75 4.9. Prefix Aggregation and Scalability . . . . . . . . . . . 13 76 4.10. Incentives for Deployment . . . . . . . . . . . . . . . . 13 77 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 8.2. Informartive References . . . . . . . . . . . . . . . . . 17 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 The idea of IPv4 subnet has been imported intact into IPv6 networking 88 so that each subnet (link) in an IPv6 site is assigned a separate 89 subnet ID (SID). As a result, the IPv6 host has to change the link 90 prefix every time it moves from one link to another even within the 91 same site or routing domain; you have to install MIPv6 agents [MIPv6] 92 on every intra-site router and a MIP6 client on every mobile node in 93 order to provide intra-site node mobility. It might be challenged 94 whether this legacy way of IPv6 operation should continue to be the 95 best way in networking environments ever evolving to a form vastly 96 different from that of the past. 98 For one thing, scalability, one of the main reasons for subnetting, 99 might bear different implications from the past. Moor's Law has 100 continued to be relevant for decades since the time IPv6 was first 101 conceived, and cost or performance concerns for memories and 102 processors have been dramatically relaxed. There might be many 103 potential network administrators who would consider to weigh the 104 burden of managing SIDs and the associated MIPv6 infrastructure 105 against that of inherent mobility support by link-state routing. 107 This document proposes to change the operation of IPv6 networking by 108 deprecating the SID. That is, the value of SID shall be set to zero. 109 This results in all intra-site nodes carrying the same prefix and the 110 mobile nodes keeping the same address as long as the mobility is 111 confined within a given site. 113 A number of operational efficiency might result from this change. 114 The price to pay might be some changes in the procedures for neighbor 115 discovery (ND) and duplicate address detection (DAD). This document 116 presents how this new operational paradigm, to be abbreviated as 117 SID6, could be constructed and discusses possible impacts from this 118 change. 120 It is to be noted that this document limits its SID6 discussions to 121 the case of a site consisting of a single routing area; there are no 122 Level 2 routers in the site under discussion. The multi-area case is 123 left for further study. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [KEYWORDS]. 131 This document introduces the following terminology. 133 DA: Duplicate Advertisement. A unicast message, back to the source 134 address of the previous DS message received, to report the duplicity 135 of the target address in the DS message. 137 DS: Duplicate Solicitation. A site-wide multicast message to solicit 138 the response from a node in possession of the same address as the 139 target address in this message. 141 3. SID6 Construction 142 3.1. IPv6 Address 144 The IPv6 address type of interest is the Global Unicast address (GUA) 145 which contains the SID and interface ID (IID) [v6ADDR]: 147 IPv6 GUA 149 = (interface address) 151 = (subnet prefix, IID) 153 = (global routing prefix, SID, IID) 155 Now, we reset the SID, and the IPv6 GUA will no longer depend on the 156 SID; it doesn't change as a node moves across subnets (links) within 157 a site: 159 IPv6 GUA 161 = (interface address) 163 = (subnet prefix, IID) 165 = (global routing prefix, null, IID) 167 Furthermore, we change the use of the IID as the node ID (NID). That 168 is, each node is associated with an NID unique within a site. When a 169 node has multiple interfaces, there would be multiple IIDs 170 associated. In that case, we enforce all IIDs to be the same, thus 171 ensuring a unique NID per node. The result is: 173 IPv6 GUA 175 = (node address) 177 = (subnet prefix, NID) 179 = (global routing prefix, null, NID) 181 This unique NID is invariant within a site or routing domain. The 182 address is now a node address, not an interface address. 184 When a site is multihomed on multiple upstream networks, it would be 185 associated with multiple site prefixes and hence every intra-site 186 node would be associated with multiple addresses. For seamless site- 187 multihoming in such an instance, a node should be able to receive 188 inbound packets destined to any of its multiple addresses, and also 189 be able to source outbound packets with one of such multiple 190 addresses as appropriate [DASv6]. 192 Remember all we do here is to reset the SID. And that, it is not any 193 change in the definition of the IPv6 address format, but is just an 194 operational choice. All other effects are natural corollaries 195 thereof; the basic IPv6 mechanisms remain the same. We will 196 subsequently see how other parts of the IPv6 networking continue to 197 work correctly as usual, with minimal modifications where necessary. 199 3.2. Neighbor Discovery 201 Addresses involved in ICMPv6-derived [ICMPv6] ND messages [NDv6] are 202 either All-Nodes multicast addresses (FF02:0:0:0:0:0:0:1) or All- 203 Routers multicast addresses (FF02:0:0:0:0:0:0:2), both of which being 204 agnostic to SID. Otherwise, the involved addresses are unicast or 205 anycast addresses which are not anymore dependent on SID as 206 prescribed by SID6. The resulting link prefixes (global routing 207 prefix + null) advertised by all routers within a site are the same, 208 except for the inter-router point-to-point links [p2p127]. Although 209 substantially simplifying router configuration in regard to prefix 210 loading, this SID deprecation necessitates a change in on-link 211 determination. The original ND [NDv6] specifies that an address is 212 considered to be on-link if: 214 1. it is covered by one of the link's prefixes (e.g., as indicated 215 by the on-link flag in the Prefix Information option), or 217 2. a neighboring router specifies the address as the target of a 218 Redirect message. 220 3. a (solicited) Neighbor Advertisement message is received for the 221 (target) address, or 223 4. any ND message is received from the address. 225 The latter two, however, have been deprecated by [v6SUBNET]. 227 Criterion 2 should continue to be valid in SID6. However, Criterion 228 1 is of no more use since all links share the same prefix(es) 229 throughout the site, except for the inter-router point-to-point links 230 [p2p127]. Hence, a prefix with the on-link flag set is not a 231 guarantee that a neighbor address with the very prefix is on-link. 233 Since on-link determination cannot be done through prefixes provided 234 by a pair procedure of Router Solicitation (RS) and Router 235 Advertisement (RA), some other means has to be secured. We propose 236 to use the Reachability test for the purpose and thus to accommodate 237 the following procedure to the ND protocol for on-link determination: 239 o When a node is first injected into a site and attaches to a link, 240 it might acquire the prefix information through a pair of RS and 241 RA, and auto-configure itself with a node address sanitary-checked 242 through DAD described in Section 3.3. If the node comes from a 243 different link in the same site, these steps should be skipped. 245 o It then multicasts an unsolicited Neighbor Advertisement (NA) to 246 the link-local All-Nodes address, FF02:0:0:0:0:0:0:1, to 247 explicitly notify all other nodes on the same link of its 248 emergence. The source address of this NA SHALL be the node 249 address of the new node, and its link-layer address SHALL also be 250 included as an option. In addition, a new option SHALL be 251 incorporated to indicate that every recipient of this unsolicited 252 NA SHOULD return a unicast NS back to the sender. Since NA 253 transmission is unreliable, it can be repeated 254 MAX_NEIGHBOR_ADVERTISEMENT times [NDv6] . The first NA SHOULD be 255 issued after a random delay between 0 and 256 MAX_RTR_SOLICITATION_DELAY [NDv6] to avoid race condition among 257 multiple newly emerging nodes. 259 o On receipt of this unsolicited NA, other nodes on the link SHOULD 260 return Neighbor Solicitation (NS) back to the new node. In this 261 action, issuing of each NS SHOULD be random delayed to avoid race 262 condition. Also, the link-layer address of the responding node 263 SHALL be included in each NS. Duplicate NAs received through 264 retransmission SHALL be silently ignored. 266 o Successful receipt of such a returning NS confirms the forward 267 reachability from the new node's perspective; the responding 268 address is declared to be on-link. The new node creates an entry 269 for the responding address in Neighbor Cache, with the on-link 270 flag set. This is done for each responding address. 272 o For each of such returning NSs, the new node unicasts an NA to the 273 responding address. Successful receipt of this NA by each 274 responding node confirms reachability from the responding node's 275 perspective; the address of the new node is on-link. The 276 responding node then creates an on-link entry for the new node's 277 address in its own Neighbor Cache. 279 o Addresses in Neighbor Cache of a node acquired only through this 280 procedure SHOULD be considered and flagged as on-link. 282 This new procedure differs from the existing ND procedure in that on- 283 link determination is made not through Prefix List (for prefixes with 284 on-link flag set) but through Reachability tests between neighbors. 285 The role of Prefix List reduces simply to providing the common 286 prefix(es) for the given site. Another difference is in regard to 287 the semantics of the source address for NA and NS; whereas it is the 288 sender's interface address in the original ND, it is its node address 289 in SID6. 291 With the introduction of this revised procedure for on-link 292 determination, it follows that Criterion 3 of the original on-link 293 determination SHOULD be revived: 295 When a solicited NA message is received for the target address, 296 the address is confirmed to be on-link. 298 Criterion 4 remains deprecated. 300 3.3. Duplicate Address Detection 302 DAD per IPv6 Stateless Address Autoconfiguration (SLAAC) is done for 303 all unicast addresses by use of a pair of link-local ND messages, 304 namely, NS and NA [SLAAC]. NSs are musticast to link-local 305 Solicited-Node address [v6ADDR]: 307 link-local Solicited-Node address: FF02:0:0:0:0:1:FFXX:XXXX 309 In SID6, however, DAD should be done site-wide, and hence new site- 310 local messages should be introduced to do the job. 312 We name the new pair of ICMPv6 messages as Duplicate Solicitation 313 (DS) and Duplicate Advertisement (DA). Also, we introduce a new type 314 of multicast address named site-local Solicited-Node address defined 315 in a way similar to the (link-local) Solicited-Node multicast address 316 [v6ADDR]: 318 site-local Solicited-Node address: FF05:0:0:0:0:1:FFXX:XXXX 320 A site-local Solicited-Node address is formed by taking the low-order 321 24 bits of an (unicast or anycast) address and appending those bits 322 to the prefix FF05:0:0:0:0:1:FF00::/104 resulting in a multicast 323 address in the range 325 FF05:0:0:0:0:1:FF00:0000 ~ FF05:0:0:0:0:1:FFFF:FFFF 327 A DS is multicast to a site-local Solicited-Node address formed with 328 the unicast or anycast address of the target node. If the target 329 address of the returning DA is tentative, it is an indication that 330 the address is a duplicate. Both nodes SHOULD then refresh their 331 addresses and repeat DAD until no duplicates are observed. An 332 address is considered site-unique if none of the tests equivalent to 333 the ones in Sec. 5.4 of [SLAAC] indicate the presence of a duplicate 334 address within RetransTimer milliseconds after having sent 335 DupAddrDetectTransmits DSs. A natural corollary of this site-wide 336 DAD is that uniqueness of the NID(s) is confirmed site-wide. 338 3.4. Interior Gateway Protocols 340 A link-state Interior Gateway Protocols (IGP) is to be used in SID6; 341 OSPFv3 [OSPFv3] or IS-IS for IPv6 [ISISv6][ISISv4]. The most 342 important impact of SID6 on these link-state routing protocols is the 343 way routers locate the hosts; they are not anymore locatable by link 344 prefixes. 346 In SID6 operation of OSPFv3, host routes are to be included in intra- 347 area-prefix-LSAs. For each of these host routes, the PrefixOptions 348 LA-bit SHOULD be set and the PrefixLength SHOULD be set to a host 349 PrefixLength; see Sec. 4.4.3.9 of [OSPFv3]. In SID6 operation of IS- 350 IS for IPv6, host routes are to be included in the IPv6 Reachability 351 entries, and will be handled in the same way as other IPv6 352 Reachability entries [ISISv6][ISISv4]. 354 It is to be noted that SID6 of this document focuses on a single-area 355 operation in a site. The multi-area case is left for further study. 357 3.5. Other Address-Related Protocols 359 DHCPv6 [DHCPv6] is not affected since most addresses involved there 360 are link-local. The site-local All_DHCP_Servers multicast address in 361 the case of Relay Agent is also intact for correct operation. 363 Default Address Selection [DASv6] is not affected, either. One thing 364 to note is in regard to the scope comparison in selecting a source 365 address for a multicast destination address; see Sec. 3.1 of [DASv6]. 366 The scope of the node address as defined in SID6 is global as well as 367 site. Hence, the same source node address would be selected for a 368 multicast destination address of site scope as well as of global 369 scope as appropriate. 371 No other IPv6-address related protocols are affected, to the best 372 knowledge of the author. 374 3.6. Generalization 376 The description of SID6 so far has been based on nullifying the SID. 377 Alternatively, the same field can be used in a way similar to Unique 378 IPv6 Prefix Per Host [Uv6pH]. The field originally occupied by SID 379 can be populated by random numbers to render intra-site local 380 prefixes. Each node in the site is then assigned a unique (global || 381 local) prefix: 383 IPv6 GUA 385 = (node address) 387 = (prefix, NID) 389 = (global prefix, local prefix, NID) 391 How to use this local prefix is up to the discretion of each node. 392 If a node is a host, it can generate a 128-bit address by use of the 393 combined (global || local) prefix and SLAAC as described in [Uv6pH]. 394 If a node is a router, it is in fact the border router of a child 395 site wherein all internal nodes share the same specific unique 396 (global || local) prefix given to the router. 398 If the original SID field is wide enough, it can be replaced with a 399 tuple of multiple local sub_prefixes so that a recursive routing 400 hierarchy could be installed within the original site: 402 IPv6 GUA 404 = (node address) 406 = (prefix, NID) 408 = (global prefix, local prefix, NID) 410 = (global prefix, (local prefix 1, local prefix 2, ..., local 411 prefix N), NID) 413 For example, local prefix 1 could be appended to the global prefix to 414 assign a unique (global || local 1) prefix to every node in the 415 sub_routing_tier 1. Then within each such (virtual) node, the next 416 local prefix could be appended to assign a unique prefix to every 417 internal nodes in the sub_routing_tier 2, etc. This incremental 418 building of the local routing hierarchy can recur until all local 419 sub_prefix components are concatenated. 421 By now, it is apparent that the concept of 'node' in SID6 is a 422 recursive abstraction of a network entity within a tier of the local 423 routing hierarchy. A 'node' can really be a physical node, or it can 424 represent a 'virtual' node which in fact forms a intra-node child 425 site for itself. If any 'virtual' node would terminate the recursion 426 by shifting to a physical node, it can generate a 128-bit address by 427 use of its given unique prefix. Routes managed by routers in any 428 specific local routing tier n, 1 <= n <= N, are the host routes of 429 PrefixLength which equals the length of the combined prefix up to the 430 very tier n, (global prefix || local prefix 1 || ... || local prefix 431 n). 433 Also, it is to be noted that, although SID is not there anymore, 434 there do exist subnets. The only difference is that, with SID6, a 435 subnet is not identified by its SID but by the NID of the Default 436 Router (DR). DR keeps, in its Neighbor Cache, the list of intra- 437 subnet (on-link) hosts for relaying packets in and out across the 438 subnet boundary. There may, of course, be multiple routers 439 associated with the same subnet, and one of them would act as DR as 440 usual. 442 As a result of the described generalization, the architecture of SID6 443 could be summarized as follows: 445 o SID6 is a recursive IPv6 networking architecture wherein sites are 446 recursively repeated inwards (and possibly also outwards). 448 o A site is a collection of (virtual) nodes wherein all nodes share 449 the same prefix. 451 o A subset of directly connected intra-site nodes bordered by one or 452 more router(s) is called a subnet. Thus, a site can also be 453 defined as a collection of subnets. Each subnet is identified by 454 the NID of DR. 456 o Intra-site mobility is provided by a link-state routing protocol, 457 whereas inter-site mobility is by MIPv6 agents installed on one or 458 more site border router(s). 460 4. Consequencies 462 4.1. Recursive Networking 464 As described in Section 3.6, SID6 presents a recursive IPv6 465 networking paradigm. By recursion, it follows that SID6 is scalable. 466 That is, SID6 is a scalable recursive IPv6 networking paradigm. 468 4.2. No Locator/ID Separation 470 SID6 does not introduce a separate number space extra to that already 471 existing IPv6 address space; no locator/ID separation (LIS) is 472 pursued. Within a site, the NID identifies a node whose locality is 473 determined through an interior link-state routing protocol. Between 474 sites, the site prefix both identifies and locates a site. 476 4.3. Inherent Interior Mobility 478 The most important consequence of SID6 is that the node address is 479 invariant across links as long as the node resides within a given 480 site. Since the node address is used for transport connections, the 481 latter do not break while nodes move around within a site. That is, 482 intra-site node mobility is inherently provided. Locating a given 483 node is done through a normal link-state routing protocol like OSPFv3 484 or IS-IS for IPv6. No extra locators are incorporated in SID6. 486 When a given node is a router, node mobility essentially means subnet 487 mobility. A whole subnet, along with the router(s) and attached 488 hosts, can move around within a site without losing reachability and 489 transport connections. Instantaneous event-driven link-state updates 490 will keep tight track of the moving subnet and its associated nodes. 492 A following consequence is that no Mobile IP protocol like MIPv6 493 [MIPv6] is necessary for intra-site mobile nodes. A MIPv6 client 494 would be enabled only when a node visits a foreign site, and MIPv6 495 agents need be installed only on site border routers, not on every 496 intra-site routers. This simplification may stand for a substantial 497 resource saving in providing intra-site mobility. 499 4.4. Faster Interior Mobility 501 Now a valid question might be whether the intra-site mobility 502 provided by link-state routing protocols should be faster or slower 503 than that provided by MIPv6-installed intra-site routers. First of 504 all, movement detection by a mobile node should be the same for both 505 cases; any of link-layer indication, DR not reachable, or a new 506 prefix heard from RA, etc.; see Sec. 11.5.1 of [MIPv6]. Differences, 507 if any, should be with the actions taken thereafter. Typical actions 508 by a mobile node after movement detection, in accordance with MIPv6, 509 should be: 511 1. Send RS (if no RA heard) 513 2. Receive RA 515 3. Create addresses including care-of-address 517 4. DAD for all unicast addresses 519 5. Register care-of-address with Home Agent (HA) 521 Since the prefix acquired in Step 2 should be the same as the one 522 already installed on the SID6 mobile node, Step 3 is to be skipped in 523 SID6. Step 4 is not necessary, either, since uniqueness of the 524 NID(s) has already been guaranteed by a previous site-wide DAD before 525 the move, in accordance with the new DAD procedure introduced in 526 Section 3.3. Saving a DAD could be substantial since it would 527 involve a number of message exchanges appended by possible 528 retransmissions. 530 As for the last step, registering with a MIPv6 HA may consume several 531 Binding message exchanges. In the case of SID6, the modified ND 532 procedure described in Section 3.2 would be executed, which would 533 then be immediately followed by DR flooding an event-driven link- 534 state update to inform all other intra-site routers of the successful 535 arrival of the visiting mobile node. Time lapses caused by the two 536 schemes could be considered approximately equal. 538 As a result, the time saving in SID6 should be what the address 539 creation and a DAD would consume. Thus, the intra-site mobility 540 provided by SID6 should be faster by as much than that by MIPv6. 541 This faster mobility would be an advantage in many disruptive 542 applications wherein nodes might experience frequent changes in link 543 attachment. 545 4.5. Legacy Exterior Mobility 547 Exterior mobility would be done through MIPv6 as usual. MIPv6 agents 548 need be installed only on site border routers. 550 4.6. Legacy Migration and Multihoming 552 Renumbering at migration can be done seamlessly as usual. The site 553 would first be multihomed on the old as well as the new upstream 554 networks. Once all nodes are successfully renumbered and 555 corresponding DNS records are updated, the old addresses would be 556 removed and the site would be single-homed on the new upstream 557 network. 559 If a host is multihomed on different links within a single-homed 560 site, the node would be associated with only one node address since 561 the prefixes would be the same for all different links. The node can 562 be reached through any of these links. With the usual IPv6 or some 563 LIS protocols [HIP][ILNP], each interface of the node would be given 564 a distinct locator so that the peer node should choose between 565 multiple locators to reach the same node, which task being either 566 arbitrary or complicated. With SID6, however, the node is associated 567 with a single node address so that there'd be no confusion or extra 568 work burden on the part of the peer node. 570 If a host is multihomed on different sites, the node would possess 571 multiple node addresses each derived from different site prefixes. 573 Each of such node addresses is used to reach the node via the 574 corresponding site network. 576 If a subnet is multihomed on different sites, only the nodes within 577 the very subnet would be given multiple node addresses each derived 578 from prefixes of the different sites. Nodes in other subnets would 579 not be affected. 581 If a site is multihomed on different upstream networks, all internal 582 nodes, either hosts or routers, would be given multiple node 583 addresses derived from different site prefixes assigned by different 584 upstream networks. 586 4.7. Usual Use of NPTv6 and ULA 588 As an alternative to the approaches of migration and multihoming 589 described in the previous subsection, use of IPv6-to-IPv6 Network 590 Prefix Translation [NPTv6] and Unique Local Address [ULA] can also be 591 considered as appropriate. 593 4.8. Incremental Deployability 595 SID6 can be deployed incrementally. A site can adopt SID6, yet the 596 external behaviors exposed to DFZ remain the same as with a legacy 597 IPv6 site and so cause no disturbance to DFZ. 599 4.9. Prefix Aggregation and Scalability 601 Prefix aggregation in DFZ is done as usual. That is, DFZ routing 602 scalability of SID6 is as good as the legacy IPv6 networking. 604 4.10. Incentives for Deployment 606 An apparent incentive to deploy SID6 should be that transport 607 connection resilience for intra-site mobile nodes can be provided 608 with no extra infrastructure like mapping servers found in most LIS 609 protocols [HIP][ILNP][LISP], resulting in a significant resource 610 saving. An equivalent incentive in comparison with the legacy IPv6 611 networking would be that intra-site mobility, and that faster, can be 612 provided inherently by any interior link-state protocols, with no 613 hassle of installing MIPv6 functionalities on every router in a site. 614 Considering that a site can be arbitrarily large, this can be a 615 considerable additional resource saving in terms of network 616 operation. 618 5. Conclusions 620 A new IPv6 networking paradigm called SID6 is introduced, wherein the 621 IPv6 SID is deprecated, that is, set to zero or replaced by a local 622 prefix tuple. As a result, a node is associated with a site-local 623 NID, instead of one or more link-local IIDs as with the legacy IPv6 624 networking. 626 With SID6, the task of simultaneous identification and location of a 627 node, wrestled with by other LIS solutions through separate (ID and 628 locator) number spaces, is accomplished without introducing a number 629 space extra to that already available for node addresses. 630 Furthermore, the job is done stepwise across two adjacent tiers; 631 intra-site and inter-site: 633 o Within a site (intra-site), identification is provided through the 634 NID or the local prefix while location is through an intra-domain 635 link-state routing protocol. 637 o Across sites (inter-site), identification is provided through 638 (global) node addresses while location is by the site prefix. 640 With SID6, there's no need for deployment and management of the 641 mapping servers (IDs versus locators), which should be a substantial 642 resource saving over usual LIS solutions. 644 An additional advantage of SID6 is that intra-site mobility is 645 provided inherently by a link-state protocol, and that faster and 646 more efficiently than with MIPv6. Moreover, MIPv6 agents need be 647 installed only on site border routers, not on every intra-site 648 router, thus resulting in another notable resource saving. 650 Behaviors of a SID6 site externally exposed to DFZ remain the same as 651 with usual legacy IPv6 sites, enabling incremental deployment. 653 This document has presented SID6 only for the case of a single-area 654 routing domain. The case of a multi-area domain is for further 655 study. Application of the equivalent idea to IPv4 networking is also 656 left for further study. 658 6. Security Considerations 660 SID6 should be as secure or insecure as the legacy IPv6 networking. 661 As for privacy, there are documents for hiding node locality within a 662 site [SLAACPRIV][IIDSv6][IIDOPAQUE]. Randomizing IIDs works fine 663 with SID6 since randomizing takes place only at node 664 (re-)initialization once or not frequently enough [SLAACPRIV]. 666 IID hashing is a function of not only the global routing prefix but 667 also SID [IIDSv6][IIDOPAQUE]; when a node moves to a foreign link, a 668 new IID would be generated to hide the locality of the node from 669 other hosts. In SID6, the hashed NID would not change at such an 670 intra-site move, and hence its locality would be exposed. However, 671 this exposure is only to the routers which keep locality information 672 of nodes in their routing tables which are opaque to hosts. Hosts 673 have no clues which link other nodes reside in or have moved to, 674 except for on-link nodes in Neighbor Cache. Hosts would simply rely 675 on DRs for packet deliveries to off-link nodes. Therefore, the 676 privacy offered by [IIDSv6][IIDOPAQUE] would be scarcely affected. 678 7. IANA Considerations 680 There are no requests to IANA at the current stage of the document. 682 8. References 684 8.1. Normative References 686 [DASv6] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 687 "Default Address Selection for Internet Protocol Version 6 688 (IPv6)", RFC 6724, DOI 10.17487/rfc6724, Sep. 2012, 689 . 691 [DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 692 C., and M. Carney, "Dynamic Host Configuration Protocol 693 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/rfc3315, Jul. 694 2003, . 696 [ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 697 Control Message Protocol (ICMPv6) for the Internet 698 Protocol Version 6 (IPv6) Specification", RFC 4443, 699 DOI 10.17487/rfc4443, Mar. 2006, 700 . 702 [IIDOPAQUE] 703 Gont, F., "A Method for Generating Semantically Opaque 704 Interface Identifiers with IPv6 Stateless Address 705 Autoconfiguration (SLAAC)", RFC 7217, 706 DOI 10.17487/rfc7217, Apr. 2014, 707 . 709 [IIDSv6] Gont, F., Cooper, A., Thaler, D., and W. Liu, 710 "Recommendation on Stable IPv6 Interface Identifiers", 711 RFC 8064, DOI 10.17487/rfc8064, Feb. 2017, 712 . 714 [ISISv4] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 715 Dual Environments", RFC 1195, DOI 10.17487/rfc1195, Dec. 716 1990, . 718 [ISISv6] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 719 DOI 10.17487/rfc5308, Oct. 2008, 720 . 722 [KEYWORDS] 723 Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, 725 DOI 10.17487/rfc2119, March 1997, 726 . 728 [MIPv6] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 729 Support in IPv6", RFC 6275, DOI 10.17487/rfc6275, Jul. 730 2011, . 732 [NDv6] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 733 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 734 DOI 10.17487/rfc4861, Sep. 2007, 735 . 737 [NPTv6] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 738 Translation", RFC 6296, DOI 10.17487/rfc6296, June 2011, 739 . 741 [OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, Ed., 742 "OSPF for IPv6", RFC 5340, DOI 10.17487/rfc5340, Jul. 743 2008, . 745 [p2p127] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 746 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 747 Router Links", RFC 6164, DOI 10.17487/rfc6164, Apr. 2011, 748 . 750 [SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 751 Address Autoconfiguration", RFC 4862, 752 DOI 10.17487/rfc4862, Sep. 2007, 753 . 755 [SLAACPRIV] 756 Narten, T., Draves, R., and S. Krishnan, "Privacy 757 Extensions for Stateless Address Autoconfiguration in 758 IPv6", RFC 4941, DOI 10.17487/rfc4941, Sep. 2007, 759 . 761 [ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 762 Addresses", RFC 4193, DOI 10.17487/rfc4193, Oct. 2005, 763 . 765 [Uv6pH] Brzozowski, J. and G. Van De Velde, "Unique IPv6 Prefix 766 per Host", RFC 8273, DOI 10.17487/rfc8273, December 2017, 767 . 769 [v6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing 770 Architecture", RFC 4291, DOI 10.17487/rfc1149, Feb. 2006, 771 . 773 [v6SUBNET] 774 Singh, H. and W. Nordmark, "IPv6 Subnet Model: The 775 Relationship between Links and Subnet Prefixes", RFC 5942, 776 DOI 10.17487/rfc5942, Jul. 2010, 777 . 779 8.2. Informartive References 781 [HIP] Moskowitz, R. and P. Nikander, "Host Identity Protocol 782 (HIP) Architecture", RFC 4423, DOI 10.17487/rfc4423, May 783 2006, . 785 [ILNP] Atkinson , R., Bhatti, S., and U. Andrews, "ILNP 786 Architectural Description", RFC 6740, 787 DOI 10.17487/rfc6740, Nov. 2012, 788 . 790 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 791 "Locator/ID Separation Protocol (LISP)", RFC 6830, 792 DOI 10.17487/rfc6830, Jan. 2013, 793 . 795 [SID6P] Kim, YH., Kim, DY., and JW. Park, "IPv6 Networking with 796 Subnet ID Deprecated", Journal of Computing Science and 797 Engineering , vol. 11, no. 2, pp. 49-57, June 2017, 798 . 800 Author's Address 802 DY Kim 803 Independent 804 Gangwon 805 South KOREA 807 Email: dykim6@gmail.com